I don't think this would break anything. That said, I be reluctant make a change like this to fix a single instance. Are there other stations submitting reports with SLP treated like this? We already have many exceptions for various types of non-conforming METAR reports in this module, but generally I'd only consider doing that if the error was reasonably common.

Are there other stations submitting reports with SLP treated like this?

I've only encountered one METAR with this structure.

I think it's probably fine to merge this, because it should be easy for later maintainers to understand how and why this was done.

If I were still working with this kind of data, I'd be tempted to add a "strict mode", that would accept only METAR that followed the WMO or US spec. If nothing else, it would be a way of documenting - in the code - what changes were made to accommodate non-conforming reports, in case any of those ever cause problems.

If I were still working with this kind of data, I'd be tempted to add a "strict mode", that would accept only METAR that followed the WMO or US spec. If nothing else, it would be a way of documenting - in the code - what changes were made to accommodate non-conforming reports, in case any of those ever cause problems.

There already is a "strict" argument passed Metar.Metar constructor. But currently it just changes the error handling behavior (whether to throw exceptions or issue warnings). How much the parser tolerates deviations from the spec(s) should probably be handled with a separate option.

Sure. In any case, to create what I was suggesting, I think you'd need to create a "strict" version of the group regex's and group-regex list. Most of the other accommodations for non-conforming METAR were made in those regex's. I can't imagine anyone's going to want to do that, anytime soon.