No, its the other way around, what i am suggesting will not cause functionality breakdowns because of multiple instances of libraries loaded and will boost performance as no multiple instances of the same library of different versions are loaded.
So, I will make myself clearer by a more thorough description.
The only conflict i faced, not only me, but so many people have complained regarding the malfunctioning of JQ effects like sliding or accordion effects for instance, check out the forums and you will get an idea of how this is causing an issue to many users.Lets go through a practical example of a problem i encountered, the header loaded a certain library say version 1.6.x for the sake of the menu, and later on the same page, another plugin , unregistered and registered and loaded say version 1.5.x, in this case its a forward incompatibility issue, if its the other way around there will be no problem because all libraries presents backward compatibility, so if the scenario was the other way around, there would have been no problem, but in the given scenario of the forward incompatibility the header wouldn't function as expected.This is one issue, the normal procedure would be using the .noConflict function but as you already know that would cause a poor page performance because of multiple instances redundant loading. The importance of the issue from my own perspective of course, is for now and the future. For now, because inexperienced users find themselves with one option if implementing what they want, and that's flash plugins, in respect to menus, widgets and most of UI effects, which is not as efficient as JQ, regarding performance, and let's not forget that performance affect your Quality score and your SEO efforts, and consequently your success, if you are targeting commercial success, and also note, that one of the main advantages of wordpress not only as a blogging tool but as a CMS as well, lies in its ease of use for the inexperienced user, and second, as we are moving to the mobile platform officially starting from the 4G, then JQ is our only option to deliver high quality and sophisticated content that's also lightweight. Now regarding my solution or proposal, is as follows:
Lets assume we will develop a table or an index to be more specific of global variables to be accessible from anywhere within the code, this is only an index, an index of all available JQ libraries, so the first field of the index would be the name of the library, and the other two fields would be a boolean, and a version number as the third and last, so lets see an example of what i am suggesting, lets say that jquery menu library ver. 1.6.x calls to be registered, the globals are checked whether its been loaded before or not,as in this example, so the boolean variable. as in this scenario, would return false, so WP loads the library, and sets the global variable for this library in the index file to true and set the version number to 1.6.x, so in any subsequent calls to the same reference library, the version is intrigued and compared to the one in the index and that would be the 1.6.x, if it was an earlier version, the call would be ignored as the loaded library will present the backward compatibility with the earlier version, and if the call is to a more recent version say 1.7.x, then the current loaded library in memory is unregistered, and the new version is loaded and the index is updated with true,version 1.7.x.This will ensure that no library is ever loaded twice in the memory, therefore, no garbage collection needed because we are acting proactively by eliminating garbage or waste instead of re-actively collect the garbage, therefore, this will boost performance in load time, therefore, better seo and page rank, the targeted inexperienced users will not avoid or waste their time in trial and errors to fix whatever was dysfunctional by activating and deactivating new active plugins sacrificing a needed functionality, so to recap the pros:
Maybe the proposed solution is not optimal, but from my perspective as a lead myself, is that simple but effective solution, that might not be final and can be optimized by various other input, but the baseline is that it can serve as a blueprint or a starting brainstorm idea that can be enhanced and optimized.
One last point, your concern that the guidelines for the plugins should abide plugins developers, but we are concerned with the ends and not the means,lets walk in their shoes, as a plugin developer, i only care about the functionality of my plugin to my targeted segment, the platform performance is not their concern, or from their viewpoint is justified. What i am suggesting was based on a personal experience with JQ libraries and their conflicts, and me myself spent more a prosperous portion of time root causing the mishap, solved it in the development phase, in which your main concern is the functionality of your product, but in the deployment phase, where your concern is performance, you will discover that the quick fix applied in the development phase created a bigger problem later on the deployment phase. You might get the big picture if you are providing media rich content, go to "http://pingdom.com" to test your load time or choose any website you like, and you will see that the majority of the page size is redundant scripts. We counteract the performance issue with caching techniques and CDNs, its like saying "waste management" versus "garbage collection", the latter addresses how efficiently we collect the garbage, but the former addresses why was waste created in the first place, its the two schools versus each other, the proactive versus the reactive, and history in all fields revealed that the former and who ever followed it was the winner.
But again, all of that is regarding performance and its counteract, but what about reliability and usability, and one other aspect is a strategic competitive advantage to tomorrow's computing:mobile computing, we might debate on this one, i agree but i guess we cant debate on the other two.
And my proposed solution is very similar to the basic concept of caching.
I am very grateful for your comment and your time, and forgive me on this one, i just agree with you that i wasn't descriptive on my former, so i hope i am on this one. Thanks Iandunn, and thanks to anyone who got the patience to be reading this line, and its and the community support that will make this wonderful platform sustain.Please don't hesitate to seek any further explanations i might not made clear.
My best regards