AddonA altering AddonB, and AddonB has been upgraded in some way that breaks A
This is my life with cyCircled. If only my suggestion for an official skinning interface for the ace community was not shot down in flames back when I was too noob here to tell whoever it was where to go.
Modification of global data of any kind (could include the hook-chain too i guess)
A sub-species of this is some noob copying say a crucial function from say AutoBar & using it as is with no modification whatsoever in their "mod". Now while the functions are identical all is well & one clobbers the other. Once something changes it becomes load order dependant & subtle to debug.
Let's flog this dead horse with a concrete example using AutoBar & the PeriodicTable-2.0 -> PeriodicTable-3.0 transition.
Ok, as an author I bitched about having to upgrade but the reasons were compelling: compressed & thus smaller data sets, better organization etc. Therefore I chose to upgrade.
The new stuff was completely incompatible with the old: keys changed, data sets got moved around, merged split apart, dropped.
What would a CL layer have done? Well:
*It would have had to maintain a table translating the old keys to the new ones
*It would have had to add old comapatability sets for each set that got merged, dropped or split
*There would be this redundant code sitting there unused by any mod that did upgrade
*Time would be spent on CL & debugging the CL & debugging old crappy unupdated mods just because maybe the CL broke something
What happens in the long term? PeriodicTable-4.0:
*Needs a CL layer for the CL layer
*Needs CL for 3.0
*Needs double the implementation time because of all this completely uneccessary stuff
*More time debugging CL
*Triple the imnplementation time
*Features dropped because the code is starting to become total crap & a nightmare to upgrade.
*Fulltime person now devoted to dealing with CCCL etc. ssues in old mods
*Never released for use as the CL stuff was too complicated for a human to upgrade within the lifespan of the universe
*Who cares about its features, nobody got it working.
Hopefully this clears up any confusion. If it does not, may I point out a real life example in Microsoft Vista? It took Microsoft over 10 years to give birth to Vista because they maintain backwards compatability all the way to the days of DOS or something sick like that. CL is crap & if u can avoid it you do so. In the case of libs simply using the old libs for lazy mods is all the CL we need which is: ZERO.
...Gains in memory consumption should, theoretically, come mostly from the frame-work agnostic libraries approach. That's a really dodgy thing, though, it's more likely you'll end up with more memory used. If it's not a significant increase, however . . . I don't really care...
Actually I think the frame-work agnostic libraries have the potential for truly huge savings since being agnostic they have a good chance of being used much more widely than the Ace libs ever were.
From the sounds of it the core clashing frameworks are on the order of 20-50k or whatever which is not really worth mentioning no matter how crappy your machine is (while meeting minimum WoW requirements).
So after my initial panic I think we can now settle down for a hard push to keep anything & everything that can be agnostic in its own LibStub(s)