Summarizing the LEWG ML review (ended on 2021-Sep-28):

• The names "take", "take_assign" were generally supported. 
• There was some concern about wrong usage:
  • My main concern is that the short name might lead users astray.  Novices will reach for existing_object = take(object) because it looks simpler, but it's not actually simpler or faster, as Section 3.4 points out. take has fewer characters than exchange, but take is more specialized.
  • (...) Here are some places where it may increase, not decrease, the error-proneness.
• There seems to be a concern about the motivation of adding std::take (considering std::exchange is provided, and it's flaws), especially about increasing the number of facilities.
  • Arthur's comments about codegen at https://lists.isocpp.org/std-proposals/2020/09/1901.php seem relevant. std::exchange is already potentially worse than just writing the same code by hand, and the proposed 'take' doesn't improve anything.
  • If an exception is thrown, there is no guarantee that other.m_keys.size() == other.m_values.size(). That makes the state of the source object other invalid, not valid-but-unspecified.  Unless the type takes other precautions, it invalidates code such as: other.erase(other.begin(), other.end());
• Some recommendations to not pursue with the paper. Alternatively, there were some suggestions to improve "std::exchange".

Outcome: I would recommend addressing the possibility of improving "std::exchange" in a new revision, as well as addressing the "safety" (validity) of the operation if an exception is thrown.
Although there were a few voices to not pursue, I would recommend that if willing, the author should make his claims in an LEWG telecon. Preferably, we should address the complete topic, including things which came up regarding std::exchange (as B3 since this is a new facility / non urgent fix).

Closing due to more than 1 year of inactivity. Please re-open if further work is expected.