If we don't mind bwc issues (and mucho work), which content fields should be considered as 'mandatory' and which ones are 'custom'? I guess author, posted and other 'meta' data belong to the first group. But are, say, body, excerpt etc really mandatory, even for 'articles'?

It depends. The wonderful thing about Textpattern and its philosophy of convention instead of configuration means that a lot of potential coding problems, conceptual usability issues, and complexity disappear because everyone knows what stuff forms part of various content types. If we start removing those, it becomes potentially more difficult to render front end content and back end UI, because we need endless tests to see if custom configurated data is available or not.

It also impacts the Just Write nature of installing the CMS, adding an article and having it appear immediately. If the first thing a new user has to do is visit some custom field area to add a body field, and create a template to display it, it's not exactly conducive to immediately publishing.

Things like the Title are important, because without those, there is nothing besides the ID to identify an article, nor even anything to click on to edit it, or search for it. We would need to use some kind of algorithm to generate the title from another field, assuming one exists and is suitable. And what would happen if there was no other suitable field? I think we currently assign the article as "unnamed" if the title is missing, but having unnamed-1, unnamed-2, etc doesn't help anyone find content.

Without a designated body field or excerpt field, we would need to remove the txp:body and txp:excerpt tags plus txp:if_excerpt. And how would we render a list of articles with the txp:article(_custom) tag if we don't have a corresponding content type? How do we even offer a default page template if we don't have any body text or even content types? No articles impacts URLs and URL schemes, and Prefs. The whole thing starts to seem rather messy, even though it is infinitely customisable.

I did try a CMS once - and I forget its name - that was a blank slate. It was insanely powerful and you could create any custom content type from any collection of fields you cared to define. The problem? I couldn't get it to actually do anything because I needed to first create a content type to house some data, then configure a route (MVC parlance) so it could be found via a URL, then create a template (I think it was in Twig) to display it. Then go and create content records of that type. And repeat that for every flavour of content I wanted. Then configure the links between fields and content types so they could be navigated, ... after a day I gave up and uninstalled it.

For Txp, I would far rather keep the articles and images and so forth as basic building blocks or silos of well-known content definitions, but make them modular so you could easily extend/hide or ultimately remove that type and create your own types instead of, or alongside, them. Then, newbies still get something to see, something to play with and learn from, but if you know what you're doing, you can remove the bits you don't want and roll your own.

Oh, I don't suggest we furnish an empty space. Nothing stops us from supplying an 'article' cf collection (body etc) by default. But they would be cfs, not part of textpattern table. We would also map <txp:body /> and other existing tags to cf rendering function in the background.

The point is, articles can be of varying nature. Remember pageless sections: their articles have no url access, they serve only for inclusion in other articles.

That works for me. So essentially we need a way to define a new content type. And map that to a bunch of fields that we can render in particular groupings (twisty subpanels). And then get the interface to draw/save/update itself based on the mapping.

Simple :)

Simple is not impossible :-) Part of it needs to be done anyway. And you are far more than me involved in cf administration. I can adapt the public part accordingly.