What would be a use case of this? Is there something inherently wrong with unix 
timestamps? Hardware has millisecond latency, I don't understand where having 
granularity down to the CPU cycle would be significant.

My immediate problem is that I am trying to generate ETags that are compatible with those generated by Apache. Apache 'MTime' is of granularity microseconds. Unless I can determine the file modification time to an accuracy better than what PHP gives me I cannot do this.

More to the point: if a facility is available, someone will find a use for it. It will not break backwards compatability since scripts that are not interested just don't look for the new members in the array.

I've got a patch that implements this, but I'm not totally happy with it right 
now — it works well enough for systems that provide this, but results in 
inconsistent behaviour for stream wrappers: whether the nanosecond fields are 
persisted depends on what's defined in sys/stat.h, since we use the system 
struct stat even though stream wrappers are theoretically decoupled from the OS.

The better fix is probably to have our own php_stat struct that contains a 
consistent set of fields and then fill it in based on what the system provides, 
which we kind of do already at a higher level in stat() and friends.

Since I got most of the way through the first version anyway, I've pushed it to 
GitHub: https://github.com/LawnGnome/php-src/compare/fr65717. Will continue 
tinkering with this to see if I can abstract away the system-specific stat 
struct as described above.

This is also mentioned in bug 78109.