Yeah, I'm imagining, I've run into these problems in the past and then the compiler told me to do it differently and so I did. I'm definitely glad that such unobvious behavior is being reduced, I just probably won't realize until I'm writing similar code the next time and the compiler does not complain.

Inline consts also let you perform static assertions, like asserting a type parameter is not a zero-sized type, or a const generic is non-zero. This is actually pretty huge since some checks can be moved from runtime to compile time (not a lot of checks, but some that were difficult or impossible to do at compile time before).

Well, as it says in the documentation I linked:

unlike canonicalize absolute does not resolve symlinks and may succeed even if the path does not exist.

Primarily, the latter part is what I want. There's just sometimes situations where a path doesn't exist (yet), but you want to know what it would look like as an absolute path.

It still returns relative paths if the input was relative

False

and it doesn’t resolve “…”

I'll assume you meant .., since ... is an ordinary filename. (Aside from the "who remembers ...?" feature introduced in Windows 95's COMMAND.COM where cd ... was shorthand for doing cd .. twice and you could omit the space after cd if your target was all dots.)

The reason it doesn't do that is that, when symlinks get involved, /foo/bar/.. does not necessarily resolve to /foo and making that assumption could introduce a lurking security vulnerability in programs which use it.