Honestly that's the worst of all worlds: Behaviour that's reliable, but not guaranteed.
People will definitely start to rely on it, and then you can't change it later when it makes sense, which means the relevant APIs can't be reworked to better treat disks as the asynchronous network devices they nowadays are. Even though the APIs are flexible enough (per documentation) to manage that.
On the flip side, when you're the developer, you can't rely on the behaviour without feeling dirty, and/or needing separate codepaths per OS because this isn't specified, and it's a bad idea to rely on if you aren't absolutely sure you're on Linux.
And then there's the fact that, while write(2) on O_APPEND is certainly atomic in most cases... I simply can't trust that's true for arbitrarily large writes, because it certainly isn't specified; it might do short writes above 64k, or 64M, or something. So I'll need an error-handling path of some sort anyway.
I don't think that write on a actual file can randomly return a partial write, unless an actual error has occurred (out of disk space, segfault on the buffer, i/o error, or an interrupt). These are all things that are either under the application control or would need to handled anyway.
I thought it could happen if you received a signal but apparently on linux signals won't interrupt file i/o. which brings back memories of processes getting stuck doing NFS I/O.
People will definitely start to rely on it, and then you can't change it later when it makes sense, which means the relevant APIs can't be reworked to better treat disks as the asynchronous network devices they nowadays are. Even though the APIs are flexible enough (per documentation) to manage that.
On the flip side, when you're the developer, you can't rely on the behaviour without feeling dirty, and/or needing separate codepaths per OS because this isn't specified, and it's a bad idea to rely on if you aren't absolutely sure you're on Linux.
And then there's the fact that, while write(2) on O_APPEND is certainly atomic in most cases... I simply can't trust that's true for arbitrarily large writes, because it certainly isn't specified; it might do short writes above 64k, or 64M, or something. So I'll need an error-handling path of some sort anyway.