I'd suggest a hierarchical approach:

1. If templates are defined, through templates (CMS_TEMPLATES setting)
   • Backwards compatible
   • Only one place to change if using both django CMS' head and API
   • Allows for additional config, namely inheritance.
2. If no templates are defined, fall back to a new setting, say,

   CMS_PLACEHOLDERS = (
       ("home", ("content", "sidebar"), _("Home page")),  # Give slot names
       ("products", ("intro", "ads", "disclaimer"), _("Product page")),
   )
   

3. If no setting exists at all: Just one placeholder per page, called "content".

If inheritance is important for a headless solution, the CMS_PLACEHOLDERS could add an optional config, despite the fact it might look clunky:

CMS_PLACEHOLDERS = (
    ("home", (
        "content",  # Shorthand for {"slot": "content", "inherit": False}
        {
            "slot": "sidebar",
            "inherit": True,
        }
    ), _("Home page")),
    ...
)

See here for an early test run: #7850 (comment)

On another note, allowing for an alternative method of placeholder declaration - besides within templates - will simplify certain use cases for app hooks:

• Currently, app hooks need to define a get_template() method on their frontend-editable models to provide a template for placeholder scanning only. Often, it only lists the placeholders using the{% placeholder %} template tag.
• Typically, a different template is used for actually displaying any model content using {% render_placeholder %} instead of {% placeholder %}

I suggest to also checking models for a get_placeholder_slots() method which will return a model's used slots. It will be evaluated in cases the get_template() method does not exist or returns a valid template.