1. There are test failures.
2. We've asked you to avoid force-pushing PRs because this makes incremental review difficult. You acknowledged this and promised to stop, but it keeps happening. Can you explain why? I am genuinely puzzled.
3. When we mark something as noexcept beyond what's required in the Standard, we comment it as // strengthened or /* strengthened */ to note this fact.
4. Many of these are incorrect. For example, deque always dynamically allocates a "proxy object" in its constructors, including its move constructor, so that must not be marked as noexcept. (deque is highly unusual in that the proxy object participates in the data structure's representation, whereas for other containers it's for debug bookkeeping. vector and string are special in that the Standard was updated to require noexcept in the default/move ctors and we decided to mark them accordingly despite the debug allocation; this is a known headache with no good solutions.)
   • Somewhat similarly, the tree containers (set etc.) always dynamically allocate sentinel nodes as part of their representation, so their move constructors must not be marked noexcept. I find it concerning that so many noexcepts are being added without any attempt to determine whether the implementations are actually capable of throwing; this makes auditing the PR for correctness time-consuming and risky.
5. Marking defaulted constructors as noexcept seems exceptionally low value; they will be noexcept if the compiler-generated code qualifies. (This can be used to enforce things - i.e. if the compiler-generated code wouldn't be noexcept, then noexcept = default; is an error - but this is rarely useful.)
   • In some cases, the addition of noexcept to = default; is incorrect. For example, for _Not_fn(_Not_fn&&), the user-provided function object might have a throwing move constructor.
   • Similarly, tuple's move constructor can easily throw.

While we can continue considering noexcept strengthening on a case-by-case basis, I think that this PR is trying to do far too much. I don't believe that we have the review capacity to merge this.

I think you should split this PR into two PRs.

• One adds some missing noexcept in <future>, no /* strengthened */ is needed.
• The other adds noexcept to stream types, /* strengthened */ is probably needed.

For containers, wrapping types, and defaulted functions, I think it's wrong to add noexcept.

We talked about this at the weekly maintainer meeting and have decided to close this PR without merging, for the reasons stated in #3278 (comment) . We remain open to considering small, targeted PRs that have been carefully thought through to be correct, such as @frederick-vs-ja's #3314.