But nothing in File is tied to "stream of bytes", it's really just an immutable ID that may or may not point at an entity in a file system. What it adds is oper

But nothing in File is tied to "stream of bytes", it's really just an immutable ID that may or may not point at an entity in a file system. What it adds is operating on filesystem attributs in a best effort WORA way, which leaves room for improvement (nio allows decidedly non-WORA digging into details I think?), but is very valuable to have because it satisfies most use cases in a more convenient way. As you said, File won't go away. But it really does not feel right to not have File implement Path, or perhaps a subset of Path that would be good enough for all those use cases where something outside the identifier acts on the identified entity. Every .toFile() and .toPath() is a little defeat in API evolution, and there are a lot of those. Do they consider addition of an new interface, to an existing class a break of compatibility? On 17 windows (that's what I happen to be looking at), a chain of toPath/toFile/toPath won't even give you a symmetrically bound pair of immutables, toPath is memoized but toFile is not. Should not have been too hard keeping a provenience reference on the other side, or have memoization on both sides?