LWG issue for the friendship bug with proposed resolution (matching this implementation) https://cplusplus.github.io/LWG/issue3882 (Thanks for pinging me about that!)

Looks good to me too. I've pushed one last commit to improve the merge with #3483's reformatting, FYI @strega-nil-ms.

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

I've pushed a commit to address several issues that I found while mirroring:

• Work around VSO-1753916 'C++23 tuple causes x86chk assertion: !"If lookup found RDSymbol before it should find something this time, too", ParseTree.cpp 10376'. This affects _Can_equal_compare_with_tuple_like_v, which uses a pattern that we've never used in the STL before. As it's used only to emit a nice error message for Mandates, I'm simply skipping it for C1XX.
• For tuple_cat(), go back to using typename _Tuple_cat1<_Tuples...>::_Ret instead of auto. This fixes a highly unusual scenario where real world code uses decltype to ask what the result of tuple_cat() of tuple<Abstract> would be. We can mechanically form the return type with the struct machinery, we just can't actually instantiate such a tuple.
• This also requires that we constrain _Tuple_cat1 in C++23 mode, identically to how tuple_cat() is constrained. This allows the entire function to SFINAE away if called with something that isn't tuple-like, such as int.

Thanks again, one more step closer to C++23! 😻 🎉 🚀