You say "based on an earlier proposal from 2013 by Matthew Fioravante," but I don't see where you actually link to that earlier proposal. You should do that.

You say "Large parts of his text were reused, following the MIT license," but on the one hand I'm sure you're not following the letter of the MIT license (since I don't see those letters anywhere in your text), and meanwhile since you don't provide a pointer to the original I would say you're not following the spirit, either. (I don't think the MIT license really applies to non-software anyway.)

You have a "References" section. That's (one of) the places I'd expect to see a link to the prior art you're talking about.

You have a "Changes compared to the 2013 proposal." That's a place I'd definitely expect to see a link to the 2013 proposal.

"We will perform...", "Let us examine..." — I recommend to cut the cruft and just say what you're proposing, and why. Partly I'm grumpy because of how that useless 14-row table rendered on mobile; but even if I weren't grumpy, I don't think the proposal benefits from that 14-row table.

You use the acronyms "PEM" and "PSEMF". Try not to need them: write out what you mean. If you must acronymize, be consistent — these are either "M"embers or "M"ember "F"unctions — pick one!

If we allow the implementor to add private member functions via

  private void Foo::newfunc() { }

  private static void Foo::newfunc() { }

then should we also allow the implementor to add private static data members via

  private static int Foo::sdm = 42;

? (Incidentally, this shows that your 14-row table is missing a bunch of rows.)

"private static" appears in the paper 11 times, and "static private" 10 times. I'm still not sure which one you're proposing. Make it clear what you're proposing. 

Can the implementor's "private extensions" include declarations, or just definitions? That is, is this permitted?

  struct S { };

  private int S::f(int x = 0);

  private int S::f(int x) { return x; }

I would think that it should be.

"Note that we cannot declare private extension default constructors, copy constructors, ..." — What do you mean "note"? You didn't mention any of this before! And why can't we? This part can't just be a throwaway line as if it's obvious from context; you actually need to explain what you're talking about here.

And what about comparison operators? Swap? Conversion functions of the form `private S::operator T() const`?

Much of the confusion in your paper could be avoided if you'd just try to write some "Proposed Wording." Figure out what sections of the Standard would have to change, and show how.

Look at existing proposals to see how "Proposed Wording" is supposed to be formatted.

HTH,

Arthur