How do you know the implicitly-declared copy constructor/assignment operator will be non-throwing? Maybe the implementation added a data member whose copy or assignment is potentially-throwing? Do we have blanket wording somewhere, or should we add this?
Otherwise generally agreed with the direction.

If we add data members etc. we still need to conform to the observable effects of as-if. Here, we would be relying on the implicit signatures of operations that are explicitly noexcept in the base class also being noexcept.

If we add data members etc. we still need to conform to the observable effects of as-if. Here, we would be relying on the implicit signatures of operations that are explicitly noexcept in the base class also being noexcept.

I don't see how that follows, given that:

17.5.2.2 [functions.within.classes] only requires the "same apparent semantics" for special members as those that would be generated by default,
17.5.2.3 [objects.within.classes] allows an implementation to provide additional non-static class members in addition to those described in the class synopsis, thus affecting what would be generated by default, and
17.6.5.12 [res.on.exception.handling] doesn't appear to place any restrictions on the exception specification of an implicit special member, or indeed on what they might throw, unless there is a Throws: paragraph or an explicitly specified noexcept.

As a result, I don't see any restriction on the exception specification of an implicit special member in the standard library. In particular, this appears to be a valid implementation of the simplified specification:

struct bad_exception : exception {
  string what_ = "bad exception";
  const char *what() const noexcept { return what_.c_str(); }
};

but it no longer has a noexcept default constructor (or copy or move constructor), and in fact the default constructor might throw.

There is [exception]/2 (added by LWG 471) which requires that "each standard library class T that derives from class exception shall have a publicly accessible copy constructor and a publicly accessible copy assignment operator that do not exit with an exception", but it does not constrain the default constructor, and I'm not sure whether "do not exit with an exception" implies that these functions have a non-throwing exception specification.

In general, the requirement "does not exit via an exception" does not imply a non-throwing exception specification. But we could certainly massage these words to simply require a non-throwing exception specification.