What I usually do is clip the data very very slightly at the antimeridian but that doesn't seem to work here. What you can try is offset it, create the buffer, clip that buffer (so that the clip will end up at the antimeridian) and then offset it back. Very clunky method I'm afraid.

Thanks for the reply. I also have a feeling it's gonna get quite cumbersome to cover this case. I was hoping that the GeographicBufferer could do it but I cannot find it in the Workbench. Does it have a different name now?

All corrective measures need to be done before buffering takes place, correct? I would prefer to do some post-processing on the coordinates and correct any Longitude >180° / < -180° after buffering but I guess this is too late since the error seems to occur in the Bufferer:

Invalid origin longitude specified in coordinate system definition `_AZMED_NEIGHBORHOOD_WGS84_-180_-67'

Reprojector: Reprojector: Failed to define equal area / equal distance projection

The GeographicBufferer now redirects to the Bufferer (which has the option of specifying the buffer units, so the GeographicBufferer is obsolete).

And yes, this does appear to happen in the Bufferer itself so you basically have to make sure the buffer will not cross the antimeridian at the time the Bufferer does its thing.

The Problem is solved! A colleague still had the GeographicBufferer on his computer since he's still working with an older version from 2019. I exchanged the GeographicBufferer.fmx file in my directory with the older version and updated the Transformer Gallery in the Workbench. I found the GeographicBufferer and used it instead of the ordinary Bufferer. It works like a charm! The coordinates do not exceed 180° and also change sign to cater for the different hemisphere. That's what I expected.

This is actually a VERY GOOD REASON to reinstate the GeographicBufferer since it has obviously NOT become obsolete. I hope Safe Software is listening here...