mandoc is trying to be smart here applying what seems to be a "relevance" comparison depending on the "bits" described in mandoc.db.5 (which we don't ship, so src/contrib/mandoc/mandoc.db.5):
0x10: The name appears in a filename. 0x08: The name appears in a header line, i.e. in a .Dt or .TH macro. 0x04: The name is the first one in the title line, i.e. it appears in the first .Nm macro in the NAME section. 0x02: The name appears in any .Nm macro in the NAME section. 0x01: The name appears in an .Nm block in the SYNOPSIS section.
...so we sort first based on these "bits". Doing direct arithmetical comparison for bitfields doesn't seem to be correct, more so I'm not sure we should care about them at all -- first section, then alphabetically seems to be "just enough" for me, i.e. I don't see why the page not having relevant .Nm in the SYNOPSIS section would sort less than one containing it if the .Dt sorts otherwise, and that's what going to happen when doing "(bits1 - bits2) != 0".
Remove the "bits" comparison to make the apropos(1) output sorting meet common expectations. With the change, apropos -s9 map no longer puts pmap(9) in between vm_*(9) pages.
Not submitting this upstream as this is NOT a bug, rather a matter of preference and common expectations.