One good reason why this doesn’t exist is that https://en.wikipedia.org/wiki/Project: is incredibly hard to link to in most circumstances (notice how : is cut-off on Phabricator), and there are also no actual issues with this (that aren’t caused by wiki abuse like MoS: links are).

https://en.wikipedia.org/wiki/Project%3A

No harder than the existing page at https://en.wikipedia.org/wiki/) AKA https://en.wikipedia.org/wiki/%29 for example. And "MoS:" is not, and never was "wiki abuse".

And since in most cases this will be a redirect does it really matter how hard it is to link to it from off-wiki?

But whatever, it's clear that we are coming at this from perspectives sufficiently different that neither of us will convince the other one of anything.

It's not a crazy idea: language links do work with an empty suffix, so that [[en:]] goes to the main page.

I think the main issue is that the redirect to "Main Page" is special cased everywhere in the code base, and it's a localized title which is often very project specific and not necessarily relevant to other namespaces. I don't think [[MOS:Main Page]] or [[WP:Main Page]] is necessarily the right resolution. I think you'd need to have a per-namespace localized message, and probably also opt out for those namespaces where this doesn't make sense

More significantly I think this is likely to break a bunch of code which assumes that title dbkeys are never empty. There would be a long tail of fixups, and probably a bunch of code that would never be cleaned up enough to make it reliably work. There's also follow on consequences with resolving titles with multiple prefixes, etc. I could be wrong about the number of places that would need a special case added, but it's a change I would attempt slowly, if at all.

opt out for those namespaces where this doesn't make sense

Why? If the page it points to is a red link then that's effectively the same as opting out.

And I think one message would work rather than one for each namespace since if that title doesn't end up ideal it can just redirect to the ideal title. But I agree projects often do ... other things ... the <mainpage> so a separate message is ideal.

More significantly I think this is likely to break a bunch of code which assumes that title dbkeys are never empty

You don't necessarily have to store an empty dbkey in the database. You could also make "Namespace:" get normalized to "Namespace:Empty" and then only things that deal with title normalization would have to care. Which is still at least three different places unfortunately.

Change #1072564 had a related patch set uploaded (by Pppery; author: Pppery):

[mediawiki/core@master] POC: Support empty-title

https://gerrit.wikimedia.org/r/1072564

Uploaded a seven-line proof-of-concept patch at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1072564. I'm aware that this would need to be copied into Parsoid and MediaWiki-title as well since the title logic is in three places for some reason, but other than that is there something wrong with this logic?

Change #1072564 abandoned by Pppery:

[mediawiki/core@master] POC: Support empty-title

https://gerrit.wikimedia.org/r/1072564

So, after fixing two early (non-database) CI failures of the form "trivially assume an empty title is invalid", that patch has 35 CI failures. About half of them are expected (testing something whose behavior is meant to change), but the other half are bizarre. And there's at least one test that I wrote which failed here, and the behavior it is testing should not change.

(That test is that setting MediaWiki:babel-category-override to an empty string disables Babel categories. With this patch it would instead populate Category:empty-title). Which I guess is technically how it should behave but super impractical, and proves the premise of the my comments above (that only MediaWikiTitleCodec and its clones would care) wrong.

So I don't think that proof-of-concept is practical.

The next idea would be to do a configuration setting "wgNamespaceBasePages". For example, on enwiki, that would be, stealing from https://en.wikipedia.org/wiki/Module:Bad_title_suggestion/override.json

$wgNamespaceBasePages = [
   NS_MOS => "Wikipedia:Manual of Style",
   NS_HELP => "Help:Contents",
   NS_PROJECT => Project:About
]

(I also set NS_CATEGORY there but that would cause the same Babel failures and is just a minor QOL thing not a fundamental requirement anyway so I'm fine leaving it out)

Does all of this make sense?

Change #1072640 had a related patch set uploaded (by Pppery; author: Pppery):

[mediawiki/core@master] POC: Add configuration setting to direct pages with no title

https://gerrit.wikimedia.org/r/1072640