No doubt this is a complicated issue, so maybe we should start small and see what shakes out. Currently, the only real conflict is wicket-datetime and wicket-contrib-yui loading duplicate or incompatible versions from different locations, resulting in multiple script refs in a page.
A lot of good ideas were tossed around in the above thread, and the only one I really didn't like is the shared jar (eg, wicket-yui). I realize that it solves the problem, but i would like to see more developer control. Also, say there is no one maintaining wicket-contrib-yui. Then it will become the responsibility of a core dev to upgrade the wicket-stuff project. An upgrade to the yui libs will also require a much higher degree of coordination between stuff and core then there has been historically. I think ultimately this will be a source of frustration. It will also hinder the stuff project from being more experimental, which is one of its missions. Also, there might be libs that wicket can not host because of license incompatibilities.
Hopefully these mumblings will inspire some comments postive and negative. If the idea is given any kind of nod, I will try to find some time to work up a patch.