Then what happens when someone uses path to query rewrites?

/wiki/Sandbox?action=edit
becomes:
/index.php?title=Sandbox?action=edit
Then no-one is able to edit...

Something like this is already possible if someone configures it that way in $wgActionPaths.
Things like this should not be automatic, because there is a strong chance that new setups may be broken by it.

(The rewrite case mentioned in comment #1 would be due to misconfigured rewrite rules -- you should use the QSA option, otherwise you break various forms in the system as it is.)

While it would be possible to append various options direct to a plain view path, there are several arguments against it. Chief among them are my favorites:

First, the lack of a consistent prefix for non-view links means they can't be excluded cleanly from robots.txt; this can lead to excessive search spider traffic. (Meta tags will keep edit pages and such out of indexes, but the spider has to load the pages to reach the meta tags.)

Second, autocomplete algorithms in browser URL bars will sometimes pick up such URLs, and you find yourself acccidentally hitting enter for a different action than you intended. Personally I find that a bit annoying. :)

The first is functional and the second is merely aesthetic, but I consider them worthy. :) My own preference for prettier action URLs is to add additional prefixes with $wgActionPaths and either stub scripts or rewrite rules, eg /edit/Sandbox

(In reply to comment #2)

First, the lack of a consistent prefix for non-view links means they can't be
excluded cleanly from robots.txt;

This is no longer the case as search engines now support glob rules: https://www.mediawiki.org/wiki/Requests_for_comment/Clean_up_URLs#Migration

Second, autocomplete algorithms in browser URL bars will sometimes pick up
such
URLs, and you find yourself acccidentally hitting enter for a different
action
than you intended. Personally I find that a bit annoying. :)

At least in Chrome, the same is actually true for the ugly /w/index.php?title=...&action=..., but in that case it is harder to get to the actual article URI by just deleting the query.

This bug is in the spirit of Clean up URLs RFC after it was slimmed down, so I'm joining them in the RFC process.

(And I support it.)

@Spage, my focus is currently more on the API portion, which is discussed in T95229: Set up an API base path for REST and action APIs. I'm still supportive of the effort to clean up edit paths etc as well, but would welcome if somebody else would champion / implement it.

Why was the RFC simply accepted with absolutely no discussion over the negative effects of blacklisting /wiki/*? which I brought up on wikitech-l and on the RFC's talkpage:

https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Clean_up_URLs#robots.txt

Making this change will make it impossible to fix the bugs in indexing of MediaWiki installations, and discussion has just skipped straight over these negative effects and approved it.

In reply to T14619#1192903:

I've created a subtask T95625 for robots.txt mentioning your concerns, on the theory that this task is about the intention and the subtasks are about the implementation. Drag this task to "under discussion" on #MediaWiki-RfCs if you want the architecture committee to reopen it.

In T14619#1192857, @Spage wrote:

Status approved by Tim Starling in http://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-08-21.00.html 2015-04-08 IRC RFC discussion,

This is meant to be: 2015-04-08 IRC RFC discussion.

+1 on DanielFriesen, MzMcBride and Bawolff.

Note that a bug has been identified with this url pattern, which may need to block further adoption of it. It's not blocked conceptually though, and the bug is certainly fixable: T123276: URL parameters do not work with pages that have "?" in their names