• redirects are always "wikitext" content, whether they're in pages named *css/js or not;

This has to be thought through carefully for security implications: Otherwise it could happen that a malicious user could edit an other user's JS page (because they are redirects and thus not protected by the edituserjs right), and make them valid and malicious JS again.

Also this translates to "Change the ContentModel depending on the Content", which sounds as a terrible idea to me. The ContentModel of a page brings all kinds of side effects with it, and if for EACH action (view, edit, api request), we need to account for the fact that the model can change at any time, then I think we are creating more long term problems than we are solving.

If "redirects should work consistently", then I propose redirects should no longer be wikitext managed as wikitext anymore, but should be 'metadata' of the page, with dedicated UI, instead of wikitext.

a malicious user could edit an other user's JS page (because they are redirects and thus not protected by the edituserjs right)

Do you mean that css/js subpages *not* corresponding to a user are not protected? I'd call that a bug.

Also this translates to "Change the ContentModel depending on the Content"

That's too general a description. Being a redirect is a page property, it's even in the database.

Redirects are supported in JavaScript content as of ad9f14d662f9597e. I'm not sure I understand what this task is asking for or why it should block T76204.

Anyone?