In reply to Trevor Nelmes.

This is one of those tasks that seems conceptually simple but in automation is not. Even in say Windows software I can link a bunch of duplicated functions into an external DLL and unless they are actually called there will be no barking. If they are attempted to be called the compiler will yell to to the ambiguity of function names, method signatures etc. But if I put it into its own namespace, no issues again as I'd need to specify in code the namespaces or add them to resource references.

While I am not yet any form of WP guru it is essentially no different than say .NET in these respects.

If assets are brought in via hooks and enqueue's, there are duplicate assets and assets that are not. Do you want a backend where it shows 250 assets lets say. WP cannot differentiate such things. Is it to do a diff against every asset? Use CRC storing and having retrieve CRC. The moment someone renames a function or puts a prefix on anything, adds even a "/**/" CRC fails.

Assets may also be hardcoded into the HTML or javascript, CSS or this or that.

Its really a much larger task that it conceptually seems like and really is more something that should be mitigated at the server not the application.

People think in WP lands from most of what I have read that using namespaces is to avoid collisions so signatures of data or functions or objects dont need be prefixed. This is true. However, thats not why namespaces simply exist. They exist for logical grouping. So with Namespaces WP could state things like "Coding standards" require the use of namespaces and assets such as bootstrap, Jquery, Modernizr, Font this and external that MUST be be in these namespace. Anything not compliant wont be available in the WP extensions DL area and "These WP functions" in said namespace are what must be used to load or instance those items. So now WP can know, "Yes we already have bootstap.js" loaded. Anything other than that is less effective and really a kludge, it'd be butchering the core code base to take care of a problem that external third party's cause.

The only other way conceptually its done is to tell all developers "Do not include any third party support code in your code" and instead those assets need be downloaded in the back end of wordpress thus supporting a plugin lets say. So the plugin need inform Wordpress on install of what external assets it needs, jQuery version this or Bootstrap version that etc. If they are already there good. If not then the user need download them from a repository and then they are registered with WP.

Either way... it negates what is out there existing. It would mean WP core need inform all template and plugin makers of the change and say, "Do it now as if you dont we wont have your stuff available for download"