So now we have no shipped preferentially treated extensions and we lack some way of distributing these. We already have TER and it works wonderfully (but could use a performance checkup). But what TER doesn't have is an official way to indicate that an extension is worth while; a favourite of the community proven to add value. Twitter has the "verified" badge, Apple's App store has the "Featured Apps". TER has a download count and graph which by the way lacks a time scale.
Why don't we introduce a "recommended" and/or "official" flag on TER? Allow such extensions to be listed specially. Raise them as top priority for suggestions. Ship the core extensions from our Swiss army knife as "official" extensions. And let the community decide which ones will get that distinction; not some arbitrary number hits from an Apache log (sincerely, no offence! I realise exactly why the solution is the way it is and I respect it! I only wish to make it better).
There's another perspective here. It's almost a tradition in TYPO3 that if XYZ does not fit our exact intention, we go ahead and roll our own. If we got around this and were able to pipe efforts into improving existing solutions I am certain we could all benefit. The examples are plenty. I don't mean to appear arrogant or hipster about this, but again: in my experience FluidTYPO3 and before that, FED, were first movers - later on joined by other alternatives like Gridelements and DCE (the former of which is at least planning to adopt the principles of Flux). This is nothing personal against those projects or their teams but they're solving the same problem already solved by FluidTYPO3. But they all make the same mistake of not relying on convention-over-configuration and not fully utilising the powers given to us through Extbase. If these efforts had gone in one direction instead, imagine where we could have been now?
So the second perspective is: having a way to selectively recommend extensions might encourage the pooling of efforts into those extensions. I hope FluidTYPO3 to be among those selectively recommended, but that's up to the community. But I digress into meta - ever so slightly.
(taken from https://fluidtypo3.org/blog/news/open-letter-call-for-conventions.html)
No offense intended, so keep calm and flush cashes. :-) The concept of Gridelements dates back to the User Experience Week in 2009, has been partly implemented into the page module of 4.5 as Backend Layouts by Steffen Kamper and myself in 2010 and then finally been applied to content as well in 2011.
One of the reasons why we did not consider FED for the content level was the sponsor's clear decision against Extbase which was a PITA back then. Since there is no need for Extbase to improve the page module of the core anyway, we were able to implement stuff with the existing hooks. In the latest 7.x compatibility branch I was even able to remove the datahandler hooks. So implementing it would be easily done by moving the draw item and page renderer methods from the hooks to the core. Still without any MVC framework overhead around.
But instead of rushing that approach into the code base of CMS, what we are asking for in the blue print is not to start with prototyping but with a clean and precisely defined plan before any line of code gets written. And therefor I kindly ask you to reconsider what you actually wrote in your post: Don't reinvent already existing things just because they don't fit your expectations in some points but really join forces instead and lets tackle that stuff together. So it will fulfill everybody's expectations in the end.
Next up would be the session at the developer days. Until then we can improve the blue print and finalize the one for the list module, since this will need to deal with nested structures as well.
Have a good night.