Fair enough, although in all honestly, "precisely" and "simply" are not words I would personally use to describe anything about POSIX's stipulations on the pax's behaviour. But as you probably know way better than I do, the whole tar standardization effort was quite a train wreck (IIRC one of the major discussions was "shouldn't we just ditch tar entirely in favor of cpio"... yeah), with lots of different people with different interests and opinions, so what we got is what we got. It's a fine format for a single-system/installation archival and backup; for portable data interchange? Not so that much. Hardened against malicious actors? Absolutely not in the slightest.
Were you involved with this process? I'm the author of the blog post, and I'm looking for people to discuss a rewrite of that POSIX pax page. What bothers me most about that section is that it prescribes that if you don't support a (vendor) typeflag, you should treat it as a header for a regular file, extract it, and continue with the next header. The problem is that vendor extensions may change the framing of the archive, and POSIX sets a precedent for that with pax headers, where you can override size=... of the next header. It should just drop that, or say that the implementation may error. There are more such improvements to be made.
I think that as of last Sunday you discovered the best place to be for that. (-:
Although now comes the hard part: filing defect reports and convincing other people.
(I maintain several of the tar parsers mentioned in this post, which I appreciate for its clear treatment of a larger differential problem in the tar ecosystem.)