tl;dr Code using QSaveFile (so Kate, KWrite, KDevelop, Gwenview & others) can result in loss of file meta data with extended file attributes, a change of file ownership and loss of hard links on existing files. Cmp. QTBUG-56366.
Wanted: Atomic changes to file content
When you are looking for a way to do transactional writes of files, QSaveFile looks like a simple and clear solution. But, this is 2016, so support for transactional updates of file content with mainstream file systems seems to be still rocket science? At least QSaveFile does a dirty hack as work-around: it creates a new temporary file to which all data is written into, and once all the content has arrived on the permanent storage, on the call of commit() it tries to replace the original file with that temporary file, by registering the new file with the name of the old in the file entries as replacement, which is an atomic system call.
Content data safely arrived, but meta data lost on the way
Just, and this is where things get dirty, this registration as replacement also will result in a replacement of all meta data for the old file with that of the new. And if the old file was registered as a hard link, that link will be dropped as well, the new file registered for the given name is now a file on its own decoupled from the formerly linked ones which also never will learn about the new content just written.
So the hack with the separate temporary file needs some more efforts to simulate a real transactional update of the content of that file identified by its name. Sadly some things are impossible and some things seem not yet implemented. Impossible is e.g. to set the ownership in most cases because for obvious reasons this needs special rights (cmp. API documentation of chown()). And e.g. not yet implemented seems to be copying of extended file attributes.
You who makes a difference?
There is no big warning sign yet on the API documentation of QSaveFile, so some developers might not be aware of these traps when using QSaveFile, like e.g. all over code in KDE projects. Or they are, but the users of their products are not (cmp. related bugs for Kate 333577, 354405, 358457).
So if you desire transactional updates of file contents in your code, consider if there are cases where the loss of the mentioned file meta data can be an issue, e.g. when those files are candidates to be shared on multi-user systems or when extended file attributes are being made use of with those files.
If you are a developer experienced with file system API, please consider writing a fix or improvement for QSaveFile and adopting QTBUG-56366: “QSaveFile results in loss of extended file attributes and change of file ownership”.
If you are a developer of file systems, please consider writing some system API which covers the use cases of transactional access to files. So there could be a proper implementation variant of QSaveFile and also any helpless hacks like .lock files would also no longer be needed.
And if you found wrong claims in this text, please shout out in the comments, as I only explored this issue quick and superficially for now, so chances are I missed something.
Attracted by virtual constructs 
I’m not right now on a linux machine, so I can’t test this, but this is something which just come to my mind:
1) Write to a new separate file copy.txt
2) If it succeeded, then do not copy file to another, but instead pipe it with ‘cat copy.txt > original.txt’, so there happens no copying, and the original file remains with attributes, meatadata and new content
3) remove copy.txt if there was no piping problems
Piping with cat (or equiv) is not an atomic operation, which is the desired behavior. It could (possibly) work around the aplpication which is writing the data (e.g. Kate) crashing during write (resulting in an incomplete file), but it would not provide an all-or-nothing delivery guarantee.
No it isn’t, but as long as underlying filesystems don’t support such atomic operations, this might resolve the metadata and file ownership problem (I still haven’t tested it).
I am not sure KDE software runs on more than just GNU or so.
Heh, there is no way to eddit a comment, so the correct sentence reads as:
I am sure KDE software runs on more than just GNU or so.
Also, I think this is better addressed on the programming level rather than “scripting”.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365512%28v=vs.85%29.aspx can be used on windows to get metadata preserved, but it requires a file to actually exist. So to use it in QSaveFile, it should be called, then checked for error code 2 if failed, and then a ‘normal’ move should take place.
I dunno what the relevant linux/posix api for this is.