core::path::Path

Risks I see in this design:

• Currently, items in core and std with the same paths are generally identical. Changing that makes it harder to correctly migrate code to no_std compatibility, and also interferes with the possible future where instead of a core/alloc/std split, we have std with feature flags. (There is, currently, one exception to this principle already, std::panic::PanicInfo, but that came with providing an alternative and deprecating the existing name.)
• Individual operating system variants or versions may have particular quirks of path parsing that std::path::Path needs to be aligned with, which may not be as simple to define as having a single Unix type and a single Windows type. (I don’t know if this there are any examples of this today.) This means that more than two syntax types would have to be introduced, and this might put Rust in the position of either causing a breaking type mismatch, or having security bugs.