TYPO3 Core

I request a feature related to TCA column select type. I currently use the select fields with their grouping functionality a lot for giving a user certain settings for the content elements.

Apart from that for more complex content elements I often also have a lot of settings that need individual user input e.g. I have a map content element, so users need to set latitude, longitude, markers, lng and lat for markers, filter groups for those markers etc.

What I would love to have is a group of input fields next to each other like in a palette, that will be saved to one database column comma seperated.
So I would like to set an items array just like for the select type, but for each item I get an input field rendered out.
I never need to filter database queries by these settings, so storing them in one column would also stay efficient. Of course to correctly access the fields either the key needs to be saved aswell or empty fields also need to be stored at least with a comma to access the correct values by index.
Handling all those fields in own database columns is unnecessary, time consuming and it's easy to loose a structured way by defining so many fields.

I know the current way to do it are flexforms, which I currently do use, but the problem is, for large setting groups its more time consuming to create the xml structure instead if a simple items array.
Additionally flexform fields can not be shown side by side like palettes so for a long settings list its hard to not loose track on scrolling down those lists and its very unnecessary to have a complete row available for a very small generic input.
On top of that I need to define each tca column type per field whereas I simply want all fields to be the same type so I end up copy pasting and repeating a lot of code.
Though I want to mention that I love the new FlexFormProcessor since v11.

Anyways, what do you think about such a column type, do you also consider this useful enough to be a core feature. I don't know too much about the internal processing of the core, but it seems to me like this might not be too hard to implement as the general structures already exist (input fields, paletts, comma-seperated-storing and CSVDataProcessor), so it would just be a different combination of those techniques.