If you want to specify terminology at compile-time, wrap your code in a 'using terms from' block. If you want to specify terminology and a default target for commands, use a 'tell application ...' block with the application name or bundle id supplied as a literal so that the compiler can read it at compile-time. If you want to specify a default target only, use a 'tell ...' block with anything other than a literal application specifier as the target.
Right now this only works for applications, not for idiologically; if the same approach was to be applied to osaxen then the language would need something like a 'scripting addition' specifier (although, as mentioned before, changing osax scoping rules now would likely cause more problems than it'd solve).
So a "terminology provider" (assuming it subscribed to the required protocols) wouldn't necessarily be limited to the application or osax packages currently used because if the nature of a package can be determined, the means to load/activate it can also.
A one-size-fits-all syntax doesn't really win you anything. Someone still needs to implement code for connecting to each class of supplier (application, osax, etc), and in practice that's going to be Apple who can easily matching object specifiers in the language while they're at it. Having different specifier names for different classes of suppliers is also preferable for users as it makes the code more descriptive and therefore easier to understand.
The only other thing your examples add are an unintuitive phrasing and extra indirection, neither of which you want in a language like AppleScript given its target audience. A statement such as:
tell application "Finder" to get name of home
may not satisfy the purists, but it's more than adequate for most AppleScripters to get started with and easy to understand. It's certainly simpler for novices to read than:
tell application id "com.apple.finder" to get name of home
while most would be put off by the much more cryptic:
associate fndr with provider "com.apple.finder"
...
tell fndr to get name of home
What could (and should) happen though is that the task of loading and invoking osax handlers should be moved out of processes and into the AppleScript component itself (which is where it should've been in the first place). Allowing the arbitrary loading of arbitrary code into arbitrary [1] processes just isn't a very good idea, and Apple are already in the process of locking down that sort of behaviour elsewhere (c.f. Input Managers).
It seems to me that the above implies some curtailment of dynamism and therefore not advantageous.
Moving osax handlers out of processes and into the AS component doesn't curtail AppleScript's dynamism. It does prevent non-AppleScript clients using them, but it's not like they'd be missing much. More importantly, it would plug another potential hole in the system. If osaxen had been implemented as language extensions from the get-go Apple wouldn't have had to plug an embarrassing osax-based security flaw in their OS a couple months back, and users running AppleScripts within privileged processes wouldn't now find their scripts unable to load any osaxen at all.
Beyond that, there isn't really much point trying to invent clever, sophisticated import mechanisms for AppleScript. They're unlikely to justify their development costs as the language just isn't that good or widely used, and it creates more complexity for users, most of whom aren't professional programmers and will benefit more from simplicity and clarity and the reuse of existing mechanisms.
Regards,