It was submitted for PDTS (proposed draft technical standard), which means it goes out for balloting to ISO national bodies. That balloting either succeeds (at which point you have a Techincal Specification) or it comes back to the committee with comments that the committee then has to respond to (and then another round of balloting happens). Once it's accepted as a Technical Specification, it's still not part of the C++ International Standard. That's a decision the committee comes to at their own pace, much like what happened at this meeting where the Concepts TS was accepted (as amended) into the IS.
Think of a TS somewhat like a beta. There's no assurance that the contents of the TS will go into the IS at all or in the exact form it was originally specified in, but that's certainly the hope when the TS is published.
Yes and no. Many compilers support #pragma once, but whether your build environment handles it is another matter. Having your headers on network drives, or having symlinks to your headers, etc can cause issues with #pragma once handling (depending on the implementation) that can often be hard to track down, especially if building with multiple compilers. Include header guards do not have these issues.
The author may be a bit confused as to what C++17 will be. Modules will be in a TS, most likely. Transactional memory, concepts, ranges, and filesystem are already in published TSes (not planned for the IS in this round). Out of the list presented, only fold expressions and __has_include are actually already voted in for C++17 itself. The rest are in various stages of standardization (mostly TSes) and are not guaranteed to ever become part of the IS (though hopefully many will).
Boost is a very large project with varying degrees of API quality, and so when you say it depends on boost, I wonder "the good parts (any, variant, stuff that usually gets looked at for standardization)" or "the bad parts (Spirit, etc)". Also, as others have said, it's a huge dependency that generally raise a red flag (for performance and compile time).
One thing to note, they split them into recommendations and rules. Recommendations are more stylistic and open to debate, whereas violations of rules generally result in definite security concerns.
I think this is a good step in the right direction, but still falls short. For instance, it's heavily gender binary, and has odd cultural mismatches such as "man with turban" but no "woman with hijab." However, major kudos to the Unicode consortium for their work on this -- it's a very challenging set of subjects to get into!
It's something we're discussing and exploring. The general thought is that Clang could do this for everything but sized deallocations (and it's unclear how much of an issue those would pose).
I apologize for being imprecise. We're aware it's more than just ADL or constexpr, but we had insufficient time to address it at this meeting. It's definitely on our radar, we flagged it as a high priority item.
This topic was discussed in Lenexa at last week's C++ standards meeting, and the direction the core working group was thinking was that this should be ill-formed, but is currently under specified. I would not rely on this ADL constexpr trick working for long (at least until CWG has had the chance to really pick apart the issue and change the wording to explicitly allow it).