This is most likely because of commit be2255928a9c3213309a1f52a134ef79f5a41d02 and the changes to autoposition.js by @Jgiannelos

This might also explain some of the other autoposition issues I've seen ppl mention here and there in the last 2 months.

So the new autoPosition.js does

var autobbox = bbox(data);
  var autoviewport = viewport(autobbox, [params.w, params.h])

But this does not account for when the elements do not fit, like the old one. They don't fit, because the first layer of the shapes is basically [ [ [ 3600, -180 ], [ 3600, 180 ], [ -3600, 180 ], [ -3600, -180 ], [ 3600, -180 ] ] ] as defined by wikimedia-mapdata.js / @wikimedia/mapdata. The old code would then slice this polygon from the first layer, if the elements did not fit.

This is a bit of a hack and apparently there were not testcases for it either.

Apparently this is still broken ?

In T305121#8008184, @TheDJ wrote:

Apparently this is still broken ?

Yes.

A small workaround while awaiting a fix, adding coordinates/frame coordinates to the mapframe parameters (I've only used the infobox template) fixes the display of the map in the frame.
The issue with labels showing outside the masked area also remains.

Also not autopositioning if multiple points are used on a thumbnail. See Module_talk:Mapframe#Second_point_does_not_show_up

In T305121#9848982, @The_Equalizer wrote:

Also not autopositioning if multiple points are used on a thumbnail. See Module_talk:Mapframe#Second_point_does_not_show_up

That's an onwiki issue with template/module that uses coordinates of the first point as map center coordinates and therefore avoids autopositioning. It expands to <mapframe ... latitude="54.491686111111" longitude="-3.5898555555556" .... This is perhaps some intentional but confusing and poorly documented template feature? It does seem to apply autopositioning if type1/id1/title1 parameters are used instead of type/id/title.

Nice observation @Pikne.