@ciencia_al_poder: An issue with offering different ways to constrain image dimensions is cache dilution. Ideally, there should be only a single URL for each thumbnail. This doesn't mean that a client can't constrain image sizes in other ways; it merely means that it might need to do some simple math to construct the URL for the size it wants.

If we accept this premise, we are left with the question of which constraint to pick. Our current thumb API URLs only restrict the width of the image, and leave the height unlimited. The alternative proposed here is to specify a bounding box, limiting both width and height at the same time.

For the most common use cases, both tend to work equally well. Doubling the size / resolution of a referenced thumb can be achieved by multiplying the size parameter from the original URL in either case. Clients with knowledge of original dimensions or aspect ratio (provided in data attributes) can request any thumb size in any of the two schemes by doing some simple math. 

The main differences in behavior only affect clients without knowledge of original dimensions, which are relatively rare:

The bounding box approach shines for grid layouts. More generally, clients without knowledge of the original dimensions / aspect ratio can request a reasonably-sized thumb easily with the bounding box. This has become more important with the 16:9 aspect ratio, as thumbs for 19:9 portrait images end up being over 3x larger (by pixel count) than landscape ones if only the width is constrained.

The width limits shines for formatting thumbs of equal width in a column. Clients can request a thumb fitting the column width without knowing the image dimensions / aspect ratio, but can end up with some very tall images, as there are no limits on the height. Since most column layouts are specified in wikitext content & original dimensions are available in that case, it is unclear to me whether any clients actually benefit from this ability in practice.

Personally, I think that the avoidance of surprises gives the bounding box variant a slight but significant edge.

I should also mention the earlier discussion about changing wikitext thumb semantics to use square bounding boxes in T351. The API design discussed here is mostly independent of the semantics of wikitext syntax, but some similar considerations were surfaced there.