page "." section-extension ( "." other-extension )*
Such a filename can be correctly split at dots without knowing what manual sections, compression tools, and other tools are in existence.
You still haven't explained why this is a valuable property, in particular why it's more valuable than preserving existing filenames for existing manpages (eg, resolv.conf(5)).
It's not more valuable than backward compatibility. We should support the existing filenames too.
It's a good design principle for data formats to stand alone and be self-describing (within reason) without relying on particular programs and their use cases. To the extent that the format is successful, the set of programs and uses cases will expand in unforeseen ways. Gzip compression with a ".gz" extension is a feature that was added relatively late in the life of manpages; subsections (3lua instead of just 3) are another. There will probably be others.As far as I can see, manpage filename encoding does not need to be a two-way process as far as automated tools are concerned. Manpage names get converted into filenames, but I see no reason for anything below the human layer to go the other way.
In the present case, it's prudent to establish a clear rule by which the filenames in man/cat directories can be taken apart to find the page, section, and other suffixes. (This precludes using ".7z" compression for manual pages, as Thierry pointed out, or else all tools which interpret manpage filenames will have to account for ".7z" as a special case.) If this rule is similar or identical to other such rules (e.g. standard filename extensions, URL encoding), so much the better.