Not just a problem for dslide but for org in general, any time a package adds keys to configure blocks or properties, these do not complete except through dabbrev etc.
The keys are likely not already in documents. The only way I can reason to make them visible is to provide functions to register various completions and then let completion backends pick up on these. Some keys may even have completions for the allowable values. The values may be dynamic. Language server features are one path to wiring these into org mode without org mode and completion backends doing work. It would be generally good for the ecosystem. However the problem will remain, how can we find the keys? Even if Emacs has a conversation with a language server, someone will have to answer regarding what completions exist. I haven't really looked into the language server implementation, but if not a tree sitter grammar for parsing, the decisions around inline markup etc are critical to making progress. I haven't been a fan of the `#+attr' requirement on affiliated keywords nor the inconsistency about not applying these for headlines. While it may be ambiguous if keywords apply to immediately following elements or the document, I don't see an issue with applying to both when there is an ambiguity. I'm not sure what the conversation around inline markup looks like, but I'm in favor of any remote definition solution like footnotes where we mark the inline region or object and then fill in the details somewhere else. Inline escaping rules and general ugliness are not my preference. Some set of decisions and tree sitter grammar would enable org to make use of the tree sitter tools for parsing, probably good for org element and font locking both. Everyone knows that. Just my +1.
