There are two competing "standards" for MOD panning: S3M-style 7-bit panning (800-880 + 8A4) and FT2-like 8-bit panning (800-8FF). OpenMPT generally uses FT2-like panning as its default interpretation (which is the one most commonly found in PC MOD files) for panning in MOD files, but can import S3M-style panning and convert it on the fly to FT2-style panning.

Interpreting the module as using 8-bit panning, all panning commands are panned hard-left (maximum value = 48 decimal out of 256, 128 = center), so OpenMPT doubles the values.
However, note that all the panning values are still exclusively to the left after this conversion. So if you save the converted file and load it again, now the maximum value is 96 out 256, which again triggers the 7-bit panning conversion.

Simply put, if you want to write a MOD file where all channels are heavily left-leaning and not a single channel is panned to the right, for whatever strange reason you would ever want to do that, you are out of luck. You will always fight against heuristics.

That's odd; I remembered using 8xx with parameters above 80 a few times and still having all the values be doubled when I reloaded (with the parameters above 80 being clamped to FF). Maybe the problem was that I saved when I had placed the left-leaning pans but before placing the right-leaning pans. I'll have to test this more later.

To be precise, panning values betwen 880 and 88F will not force 8-bit detection, based on real-world observations where modules with 7-bit panning used such values. But in general, any module with well-balanced (hah) 8-bit panning should be reliably detected as such.