We have projects that are getting great mileage from this macro right now, we'd be sad to see it go. 😰

If you look at https://github.com/ogiroux/freestanding you'll get the gist of what we're doing with it: we don't just change the inline namespace name, we also change thestd::namespace name using the macro. This was never the intended use, I realize, but it allows us to make progress with e.g. side-by-side co-existence for a large & important subset. In other words, the presence of this macro helped make libc++ adaptable the way needed it to be, and may slowly transform us into contributors even (hence netting you great mileage too).

I think your commit message is fun and terse, but it doesn't say why you're actually correct. You're explaining it here, Marshall has voiced concerns about downsides. I think your commit message should explain this and say why you think the downsides aren't relevant. That makes it easier to go back to your change in the future and understand why the change was OK without looking at this discussion.

We have std, which is opened by namespace std {, and referred to using std::.
We have std::__1, which is opened by _LIBCPP_BEGIN_NAMESPACE_STD, and is referred to using _VSTD.
Some things live in former, and some (most) in the latter.

They're different, and the fact that std:: will find things in std::__1 doesn't change that.

That's correct, however I don't think it's a big deal. Indeed, discussed it and we couldn't find a reason why we would ever want to call a function that is not in the current ABI's namespace. And even if we did, we could always use std::<ABI namespace>::function.

Sure, my point is that the commit message isn't right, and should be updated to have this rationale.

I think this means we should only ever have at most 2 versions of std::function. One for the stable ABI and potentially an improved version for the unstable ABI.

This is where we disagree -- I don't think there's a universally better implementation of std::function. One implementation might be better in some circumstances and another implementation might be better in other circumstances, hence my claim that we should not go for a solution that assumes at most two implementations.

I don't see the issue with breaking ABI that's designated as unstable as long as there's some form of announcement to avoid any confusion. Fundamentally that's the entire point of having unstable ABI versions, some changes are just not really possible to make without ABI breakages, most consumers just use the stable ABI, while unstable ABI is not backwards compatible otherwise it would make a whole range of changes to libc++ and/or Clang impossible.

FWIW, I'm slightly in favor of using different headers. For example, I just realized that this change currently leaves a bunch of baggage symbols laying around that the new code won't use, it would be easier to see that kind of thing if the internals of each function were just in it's own file.