I would also argue that this is not a build-system optimization. It
could lead to better build-times, but that's just a side benefit we get along, not the core issue we're trying to tackle.
For me the core issue is the fact that header files can easily be polluted with unnecessary things (which can worsen build times, but again, not the main concern IMO). It's the fact that when defining public API's or libraries we don't need to expose internals.
I also want to explicitly support header files and not only modules, because plenty of large codebases do not work on modules and could benefit from PEMs.
I don't advocate for re-opening the class-scope, I think that would present more problems than we would get solutions. I'd love the PEMs to be a simple feature with simple rules:
A PEM can only be accessible to 1 TU (meaning that they should always have internal linkage) and is able to access the private members of the class it extends.
It is not allowed to overload with member functions of the class it extends.
Perhaps, if this goes well, it could in the future be expanded to just re-opening the class scope? But I don't think this is the correct time to do such a thing however