• create via the API and set the contentmodel parameter (anyone can do it)

I think this requires the editcontentmodel right outside of Template:*/*.css.

I tested this in the en.wikipedia.beta.wmflabs.org API sandbox for sanitized-css and on enwiki for json and css.

{
	"action": "edit",
	"title": "User:JJMC89/sandbox/sanitized-css",
	"text": ".my-class { dispaly: none; }",
	"contentmodel": "sanitized-css",
	"token": "6e0365823f732a1a14f7111cc60daf9659cd7761+\\",
	"formatversion": "latest"
}

{
    "error": {
        "code": "cantchangecontentmodel",
        "info": "You don't have permission to change the content model of a page.",
        "docref": "See https://en.wikipedia.beta.wmflabs.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
    },
    "servedby": "deployment-mediawiki05"
}

Absolutely.

Yes, we should allow it. One of the points of ContentHandler was to remove the dependence on magic titles to know what type a page is, let's not take a step backwards in trying to reintroduce such restrictions.

Disallowing it would also cause trouble for several of the use cases described in T176269, e.g. using a user subpage as a sandbox template or using a Project-namespace page as a template.

Given that even most admins don't understand the concept of content models, this has a high potential for confusing editors.

If they don't understand them, it's because they haven't really had to understand them yet. They'll learn quickly if they need to know, just like they learn wikitext, Lua, how to protect and block, and so on.

(A somewhat related issue is that moving pages without leaving a redirect is normally an admin-level feature, but it will happen for everyone with template styles because the default content model is not wikitext so a redirect cannot be created. That's again bound to confuse people.)

That already happens with other content models that already exist. I think you're worrying far too much.

In T177027#3644980, @JJMC89 wrote:

• create via the API and set the contentmodel parameter (anyone can do it)

I think this requires the editcontentmodel right outside of Template:*/*.css.

Indeed. The check is in EditPage.php, lines 1911–1933.

BTW, there's nothing special about the API in this. The web UI edit form has hidden fields named 'model' and 'format' that can be changed for the same effect.

One of the points of ContentHandler was to remove the dependence on magic titles to know what type a page is, let's not take a step backwards in trying to reintroduce such restrictions.

Such restrictions are clearly intended, otherwise ContentHandler::canBeUsedOn would not exist. From an internal point of view, not wanting titles to be the *mechanism* of determining the content model makes sense, of course. That doesn't say anything about whether restricting certain models to certain titles is a good thing or not.

Disallowing it would also cause trouble for several of the use cases described in T176269, e.g. using a user subpage as a sandbox template or using a Project-namespace page as a template.

If we want to support those use cases, then sanitized-css should be the default content model in those namespaces for some title (say *.tcss because *.css is already used for other things). Supporting template CSS in the user namespace but not allowing them to be created in any other way than creating in the template namespace and moving seems a bit ridiculous.

In T177027#3649637, @Tgr wrote:

Such restrictions are clearly intended, otherwise ContentHandler::canBeUsedOn would not exist.

The intended use of ContentHandler::canBeUsedOn seems to be for restricting content handlers to specific namespaces, e.g. Wikibase entities in the entity namespace only. The documentation also contemplates using it for extensions in File-namespace pages.

If we want to support those use cases, then sanitized-css should be the default content model in those namespaces for some title (say *.tcss because *.css is already used for other things).

So now you're making it even more complicated.

Supporting template CSS in the user namespace but not allowing them to be created in any other way than creating in the template namespace and moving seems a bit ridiculous.

Special:ChangeContentModel, the API action=edit parameter, and the hidden field in the web UI all exist, although use of these are all restricted by a user right.

Disallowing such moves entirely is more likely to cause problems that can't be worked around in a satisfactory manner, e.g. it would be impossible to properly userify a template that has TemplateStyles CSS.

Just a note that I tried to create it using the api (I don't have editcontentmodel rights) and it wouldn't let me. I don't think that is a possibility for "anyone" to do as stated in the task

I think we should decline this task per Anomie's points and the already extent uses in any variety of namespaces on live wikis several years down the road (see an example search on en.wp). There may be some valid task, but 'disallowing use of it outside X namespace' isn't it.