If "unqualified names don't perform ADL" is the right decision, both implementations are not conforming, and the std:: before forward is redundant.

So, does it mean make_obj_using_allocator should be considered qualified with ::std::?

Yes. Because [contents] says so, and nothing says to discount [contents] here.

Does it mean that make_from_tuple and uses_allocator_construction_args are unqualified, or both of them are qualified with ::std::?

Both are assumed to be fully qualified. Our editorial policy is to consistently qualify std::move and std::forward. That doesn't mean [contents] doesn't apply.

is there any reason to make uses_allocator_construction_args above unqualified?

It's assumed to be qualified, so the question is irrelevant.

(Note that libstdc++ qualifies make_from_tuple but no uses_allocator_construction_args in the implementation of make_obj_using_allocator. On the other hand, libc++ qualifies both.)

That's simply a bug in libstdc++ (which has now been fixed).

I don't see any issue with the C++ draft here.

Our editorial policy is to consistently qualify std::move and std::forward.

I'm a bit confused. Is this policy implied in the draft? I find [allocator.requirements]/2 to omit the qualification, but no more general rules. (BTW, there are some redundant std:: in the Table 34 under this rule, and Table 33 seems actually irrelevant.)

That doesn't mean [contents] doesn't apply.

Good. Hope it clearer after #1913 is applied.

That's simply a bug in libstdc++ (which has now been fixed).

Great, though now I have to fight with not only __cplusplus, but also far more trickier __GLIBCXX__ or something else.

The text before those tables reads "Within Tables 33 and 34, the use of move and forward always refers to std​::​move and std​::​forward, respectively." That seems to be pretty clear.