> It seems to me like the goal is to simplify what's currently available, with no plan to add new features

The design is providing flexibility and extensibility in the specification of originals. I believe this covers the kind of extensions you mentioned when we last spoke about this, including rotation, cropping, or potentially effects. In order to avoid cache fragmentation, it defines simple deterministic rules for constructing the URL, and requires clients to adhere to them.

Most clients don't need to manipulate the more complex original specs, and we should aim to keep API usage for the common size & thumb type / quality selection as simple as possible. In the proposal, this is done by encoding those parameters in separate path components, making it trivial to construct the thumb URL in most cases.

> You're basically solving your own problem and leaving a considerable technical debt project on mediawiki's doorstep for someone to be determined to care about. I.e. it will be some future person's job to migrate mediawiki, its extensions, etc. to use the new URL scheme.

Once we decide to switch to an official thumb API, then we should clearly switch over all uses of thumbnails in MediaWiki & other services. The fact that current thumb URLs are private implementation details helps us here, as we are free to change their structure at any time. To make this happen, we need to establish a roadmap & clear ownership of different parts of the migration process. This RFC is intended to move us closer to an agreement on how a proper thumb API will look, and should be the starting point for the development of a migration roadmap.

> Re-reading the older parts of the task description mentioning imageinfo, you don't need to call imageinfo to generate a thumbnail URL.

Current thumbnail URLs are private to MediaWiki, and are explictly not intended or designed to be used as APIs. Clients can ignore this rule, but will break once we change our private thumb URL structure, for example by introducing a documented, stable thumb API.