As I understand it, this proposal is suggesting:

• Change the file: namespace such that it only displays files hosted at Wikimedia commons
• Creating a new LocalFile: namespace that functions identically to the existing File namespace, other than displaying only files hosted on the local wiki
• Moving all existing locally hosted files (and their talk pages) from the file: namespace to the LocalFile: namespace (this may be possible to do using bots?)

Obviously this would only be implemented if there is community consensus for it. At present a full discussion about it (at least on the English Wikipedia) has not yet taken place, although there has been limited discussion of the idea as an alternative tangentially related proposal.

In advance of that discussion taking place, this task should probably be understood to be a request for developers to communicate an understanding of:

1. Is this (or something functionally equivalent) technically feasible?
2. If so, how much effort would be required to implement it (assuming consensus)? Are we talking about a few lines of code, a couple of days work or a major project requiring significant resource?

There remain open questions, including

• What to do with local file description pages for files hosted on Commons?
• What to do with local redirects in the file namespace?
• How should disruption to articles (and other pages) using local files be minimised when the new namespace is implement?
• How should redirects from File: to LocalFile and vice versa work?

My assumption is that these sorts of questions do not need answers unless and until it is known that the proposal is technically feasible and there is a community consensus in favour of it.

A less intrusive alternative could be adding a new (optional) parameter to the extended image syntax to force a file to be sourced locally or from Commons.

I think this task should be closed as premature. Mike's proposal lacks community consensus on enwp, doesn't fix an actual problem, and should therefore not be enacted in any way, shape or form.

This would be a major project. It would involve a lot of old and ugly parts of the codebase (file backends, the parser, the Article class), most image-handling extensions would have to be updated, imagelinks tables would need a schema change, we'd have to rethink how things like the Media pseudo-namespace work... I don't think there's any chance of it happening, short of some big refactoring of how namespaces work that's necessary for some other, more pressing reason.

What's the specific problem this is attempting to solve?

I would consider instead one of:

• Show a warning when the file about to be uploaded will shadow a Commons file.
• Expose the fact that the local file being [re]uploaded shadows a remote file to abuse filters.
• Provide some kind of report about the list of local overrides.

@Tgr thank you.
The initial idea emerged in a discussion prompted by a local file being shown instead of the file from Commons a bot expected. At least on the English Wikipedia, there is already a warning if you try to upload a local file with the same name as an existing Commons file and only Admins can do it (T2889 seems relevant).
This means the problem (en.wp calls it "shadowing" I don't know if that term is used elsewhere) is almost always caused by a new file being uploaded to Commons that has the same name as an existing local file. To my knowledge there is no current way for this to be exposed to the uploader at Commons (given that it would need to check every connected wiki I'm guessing adding this would not be practical, which is backed up by T16888#189718 unless things have changed since 2009), or exposed automatically to the local wiki (this might be T18280).
There is a bot on en.wp operated by @Green_Cardamom that identifies newly shadowed files but I don't know how it works. These files are then dealt with by humans.

@MarioGom 's suggestion of being able to specify in the image syntax to use either the Commons or local image would be useful, so I've created a new task for that: T250716

T236616 seems to have a method whereby a user script can identify local files, so maybe incorporating something like that in a way that can be exposed to bots could help? (but that is a guess)

The GreenC bot uses an SQL query: https://tools.wmflabs.org/paste/view/5f36d650

In T250632#6072227, @Thryduulf wrote:

@MarioGom 's suggestion of being able to specify in the image syntax to use either the Commons or local image would be useful, so I've created a new task for that: T250716

Unfortunately that doesn't avoid most of the complexity of this task (everything that currently stores or references a file name would have to be updated to handle a filename, wiki pair instead).

Thanks Tgr, that's good to know, and has answered my question. It sounds like a no-go, so I think this ticket can be closed as resolved.

For background if you're interested, see https://en.wikipedia.org/wiki/Wikipedia_talk:Non-free_content#Requiring_non-free_content_to_indicate_that_in_their_filenames (sorry, I should have included that link in the description.)

Do note that currently, enwiki non-admins cannot upload files to filenames already "taken" by Commons files. And most instances of shadowing occur when the Commons file is uploaded later.