An expansion upon the ideas originally put forward in the CMS Group: https://groups.google.com/d/msg/joomla-dev-cms/7ommekXwB-w/Gy1BxOq9nkUJ

Joomla: A proposal for responsible and sustainable dependency management

The crux of this proposal is the removal of the initimate connection between Joomla's core and third-party libraries on which it relies, in order to provide independence and robustness to each, enabling greater flexibility and strength in Joomla. Hopefully the benefits are largely self-evident.

There are really only a couple of key components to this proposal which, while they may proving challenging to implemnent, should conceptually be easy to grasp;

1. PROTECT THE INTEGRITY OF THIRD-PARTY ASSETS
2. CONFINE VENDOR-SPECIFIC CODE TO VENDOR-SPECIFIC IMPLEMENTATIONS
______________________________________________

1. PROTECT THE INTEGRITY OF THIRD-PARTY ASSETS
There's little point in adopting a popular library, like Bootstrap or jQuery, if it is then adapted in-situ. It is, at that point, no longer the popular third-party library that was adopted, it is a derivative. The burden of maintaining, supporting and developing such derivatives then falls the to Joomla project and this is a burden that can ill be afforded. Divergence hurts us.

I propose that such third-party assets remain untouched, without exception, so that they remain carbon copies of their upstream counterparts. Contrast this to the situation we have now; Joomla does not use Bootstrap 2.3, Joomla uses the JUI a derivative of BS2.3. This makes it difficult to update, adds a maintenance burden and means that one of they prime selling points given for the adoption of this standard (ubiquity) is not true.

Wherever it as seen as necessary to modify these libraries all such modification must happen outside the asset in question. To give a clear example; JUI should not use icomoon font icons, as Bootstrap does not. This one change is a comptibility break and could be avoided very easily in Protostar's template LESS by not importing the Bootstrap icon LESS and instead declaring icomoon icons within the template. The same for Isis of course. No loss of functionality, no unused code, no compatibility break with Bootstrap.

Such an approach will also mean that multiple, and alternate, versions of such assets can all be incuded, side-by-side and without conflict. Bower makes it incredibly simple to maintain dependencies in this manner and I'd recommend it's use in this case.

In practical terms my suggestion would mean replacing (initially deprecating):

	/media/jui/

with:

	/media/bower-components/bootstrap2.3.2
	/media/bower-components/bootstrap3.1.1
	/media/bower-components/jquery1.9.2
	/media/bower-components/chosen

Of course, with such an implementation it's also trivial to include, for example:

	/media/bower-components/bootstrap-sass3.1.1
	/media/bower-components/foundation5
	/media/bower-components/pure0.4.3-pre

	/media/bower-components/jquery1.10.1

___________________________________

2. CONFINE VENDOR-SPECIFIC CODE TO VENDOR-SPECIFIC IMPLEMENTATIONS
Bootstrap 2.3 specific markup is desirable only to views that are using BS2.3 and, in fact, may be deliterious to outputs that are not. Templates are the boundary layer delimiting final output, so it is only logical that anything required, and specific to, the final rendered output be implemented there.

Currently, we have vendors-specific markup generated at the component level when such markup is only relevant at the template level. There is no guarantee that the template will even support these markup patterns and there can never be (rightly so IMO).

The relationship between generated output and any libraries it may require can only properly be set within the final point-of-truth for that output, the template. Therefore I would suggest that all vendor-specific patterns be confined to vendor-specific templates. Such an impementation would allow a huge degree of flexibility and allow fast innovation and improvement. It would, for example, be trivial to update the default Joomla output to use Boostrap3, without any breaks in backward or forward compatibility, something that we would dearly love but simply cannot do today. Protostar v1 is dependant on BS2.3, Joomla should not be. 

Vendor (and version) specific template implementations would mean Joomla is not vendor and version specific, reducing fragility, maintaining independence and promoting forward development of the CMS.

In practice this would mean removing all BS2.3 flavoured markup from core views and layouts and placing it in template overrides.

You don't need to consider classes like .label .well or .badge, these are all stylistic decisions that have nothing to do with the functionality and should be left to the designer. It's debatable that such classes should ever appear in markup, style should be implemented in css.

That's why I think designers should define a set of CSS classes, and not coders like me 😄
Currently I use the "well well-small" class to display small messages/information blocks in an upload form. One is to show the current upload limits and another one the path where the file will be stored. I guess a class like "notice" or "info" would fit better then. I actually don't care how it's styled. I just want it to be separated a bit from the rest of the form so it stands out a bit but doesn't distract.

would one way to summarize your proposal be that the goal is uncouple and simplify the markup generated by the core of Joomla so that it is easier for template developers / designers to implement other CSS frameworks and/or to use the clean, semantic, simple core markup with CSS directly?

Yes, that is one of the benefits that I can see. Others include:

1. Freeing Joomla of the maintenance burden of modified 3rd-party libs.
2. Providing extension developers the certainty that these libs are 100% reliable, e.g. that Joomla BS2.3.2 is 100% BS2.3.2.
3. Allowing upgrades of core assets and outputs, mid-cycle, without any BC breaks.
4. Ensuring compatibility issues were limited to a single location, the template.
5. Allowing mid-cycle upgrades of the front-end environment without BC issues.
6. Allowing, for example, 3.2 extensions to be run in a 6.2 site.

All of these become possible when we think of the template as becoming the compatibility layer. Crucially, all such compatibility issues would be managed in a single location.

I guess a class like "notice" or "info" would fit better then. I actually don't care how it's styled. I just want it to be separated a bit from the rest of the form so it stands out a bit but doesn't distract.

Exactly. Bootstrap's .alert and .alert-info are a great fit for such a use case. They allow me to understand exactly what you intended of those elements and I can style them accordingly.