In addition, since all flat_meows are adaptors containing the underlying container, I can't understand why their empty/size/max_size/clear are all noexcept. According to the Lakos Rule, they should not be declared noexcept because the implementation should be by calling the member functions of the underlying container, and these functions are not guaranteed to be noexcept.

The noexcept specifications don't seem to violate the Lakos Rule. These functions are required to have no preconditions and be non-failing ([container.reqmts], [sequence.reqmts], [associative.reqmts.general], [unord.req.general]).

(I believe the standard seems to pay great attention to complying with the Lakos Rule, this is also reflected in the non-noexcept empty/size of the stack/queue).

This may be an oversight.

N3187 said that empty should be noexcept because "it depends on iterator comparison which cannot throw for library provided iterators". However, the iterator comparison may eventually involve user-provided fancy pointers (see also LWG2261), of which comparison is not required to be noexcept, but merely not to throw when the comparison is well-defined.

Similarly, do we need to make exception specifications for move constructors of containers more conditional, just because copy/move construction of fancy pointers are not required to be noexcept?

Given there're already some noexcept functions that don't (or even can't) always avoid calling non-noexcept underlying operations, I think empty and size of all container adaptors should be noexcept. Let's submit an LWG issue for this.