You're not the only one who feels that way, but IMHO it's not a valid complaint.

The C++ standard says implementation defined because the weeds get very thick very quickly:

- Are paths formed with forward slash or backslash?

- Case sensitive?

- NT style drive letter or Posix style mounts?

- For relative paths, what is it relative to? When there are multiple matches, what is the algorithm to determine priority?

- What about symlinks and hard links?

- Are http and ftp URIs supported (e.g. an online IDE like godbolt). If so, which versions of those protocols? TLS 1.3+ only? Are you going to accept SHA-1?

- Should the file read be transactional?

People already complain that the C++ standard is overly complicated. So instead of adding even more complexity by redefining the OS semantics of your build platform in a language spec, they use "implementation defined" as a shorthand for "your compiler will call fopen" plus some implementation wiggle room like command line options for specifying search paths and the strategy for long paths on Windows

What if #embed steals my credit card data is a pointless strawman. If a malicious compiler dev wanted to steal your credit card data, they'd just inject the malicious code; not act like a genie, searching the C++ spec with a fine comb for a place where they could execute malicious code while still *technically* being standards conformant. You know that, I know that, we all know that. So why are we wasting words discussing it?

The real reason why this stuff in underspecified in the spec is that some mainframe operating systems don't have file systems in the common modern sense, but support C++. Those vendors push back a lot against narroed definitions as far as I know.

Including files also opens up some potential security issues that the standards committee just didn't want to prescribe solutions to. Compiler explorer hides easter eggs around the virtual filesystem, for example:

https://godbolt.org/z/KcqTM5bTr