I feel this is a bit different. At least O_TRUNC is an option that is shown in documentation right next to the open() function so the programmer has the opportunity to spot it. With the FileSavePicker, there is no such option available and they have to add a line to manually truncate the stream. Also, open() is a low-level call, whereas FileSavePicker is the supposedly easy-to-use high level feature. I would say it is closer to fopen(), which does truncate by default.

Notwithstanding the lowest-level function open() working that way (and it’s honestly a somewhat different situation due to what it is and what the flags all are), fopen(), the more user-friendly interface with its mode strings, has "w" equivalent to including O_TRUNC in open() flags: https://man7.org/linux/man-pages/man3/fopen.3.html

I only have a very basic understanding of it, but skimming it makes me think that, in addition to leaving non-truncated files full of garbage around, that kind of open, overwrite, close pattern could be problematic on BTRFS. I wonder if that's one of the scenarios where BTRFS can end up with a bunch of extents that are full of mostly un-referenced blocks, but can't reclaim space because some of the blocks in the extent are (or BTRFS thinks they are) still in use.