I think the third-party MediaWiki concerns are somewhat understated and are not actually third party as we use the same arrangement via Swift (sorry, should have spotted that sooner).

This is the status quo:
* default MediaWiki setup: thumbnails are only rendered on parse, client requests for arbitrary thumbnail sizes (arbitrary being anything that's not already present in the article) are not possible. Thumbnails are referred to by URLs which mirror the filename (generated by `MediaHandler::makeParamString`) and directory structure, so setting up the web server is as easy as configuring the image directory on disk to be the webroot for `<wiki root URL>/images`. This would probably have to be deprecated if we move along with the RfC (there is not point to an API which might or might not work).
* everything through `thumb.php`: apart from a little syntactic sugar, this is what the RfC is going for. This is a possible configuration currently although I don't think it is used much. Every image request gets streamed through PHP (or served by some external cache like Varnish).
* 404 handling: like the default, but requests for non-existent images are sent to `thumb.php` via the web server's 404 handler, and get converted from filenames back into proper key-value querystrings (via `MediaHandler::parseParamString`), then saved to disk so the next request to the same URL gets served by the web server directly. This is probably the common setup for non-small wikis.
* Wikimedia setup: basically same as 404 handling, with two extra layers on top: Varnish and Swift. Varnish caches URLs and is mostly agnostic of how thumbs are served. Swift (a distributed file storage) is used the same way as the disk in the previous example: the thumb URL uses a path/filename which can be represented in a filesystem, and in case of a Varnish miss, the "web server" (in this case a small python script) looks up the file in Swift using that path; if that fails, it forwards the request to `thumb.pgp` which transforms it into a nice query URL, renders the thumbnail, saves it to Swift then streams it.

So the proposal as it is now would duplicate thumbnail storage in Swift and degrade performance in third-party wikis that don't use a reverse proxy. It makes more sense to keep the current parameter-array -> filename-on-disk mapping and document it as standard (it's ugly and ad hoc but there are seven parameters altogether in all known extensions and almost all are mutually exclusive so meh), and reimplement it in Thumbor and the Swift router script.