What's the caching strategy for this API? Will it simply redirect/proxy to the canonical thumbnail URL we already have? Or will it do caching of its own, essentially doubling the caching capacity requirements for thumbnails?

What can a REST API for thumbnails do that HTTP and a URL scheme can't? In fact calling it REST API is a stretch, since we're only talking about GETs here. It's just a different URL scheme.

This seems to me like a cleanup without a plan to address existing usage. There isn't much insight into how this should evolve with upcoming known technologies like client hints, let alone unforeseen needs. The reason why our current thumbnail URL scheme looks weird is because it was developed incrementally with no vision about future needs. Every time a new need appeared, some kind of parameter was added. And backward compatibility could never be broken, because our images are hotlinked. The approach here seems no different, in fact the only examples provided don't even address the existing options, only a small subset of features. If you only care about id, size and quality/format the existing URL scheme isn't that awkward to use.

Explicit versioning looks nicer at a glance, but you run into the same problem of old version support and how it relates to client-side and server-side caching. And without a strategy for priming/migrating the caches for new formats, each version update would be extremely costly to deploy.

I'm all for a comprehensive plan to rethink our thumbnail URL scheme, including all existing options, planning for future needs as well as addressing the issue of migration (considering that existing URLs will have to redirect to new ones forever). But I'm not seeing anything like that here, just an eagerness to create a new endpoint that's more to your liking and does less than the status quo, without careful consideration for operational consequences and homework required to do this right. As-is, this would be creating instant technical debt.

I'll be at the meeting, but it'd be nice to have a draft spec to look at that addresses these issues by then.