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)
When you quote me about "just writing TCA" you should mention that this always came together with: We need an easy to use interface to create TCA for custom content elements automatically. There once was the extension kickstarter to do that, but it was far from being as comfortable as I would have liked it to be.
"It's almost a tradition in TYPO3 that if XYZ does not fit our exact intention, we go ahead and roll our own." - Which is exactly what you did for quite some time, because you favor i.e. "convention over configuration", Extbase, Fluid and Flexforms - So now telling other people that they wasted a lot of time because they didn't follow your approach but someone else's or the core instead does not help that much.
BTW: Please correct me if I'm wrong, but the TCA field type for grid definitions pretty much sounds like another Flexform field to me. As far as I understood, the core team on the other hand is trying to get rid of flexforms as far as possible.
We should really discuss stuff like that live and at the appropriate places, which IMHO would be Developer Days, User Experience Week and/or Core sprints. For the "Structured Content Elements" - and only for those, not for custom content, FCE, DCE or however you might call them - there is a blue print and a connected issue in the tracker, which can serve as a base for that discussion.
https://forge.typo3.org/issues/67134