fsync doesn't mean "hey kernel actually write this to disk", it means "write this to disk *now*" (and in practice, "write everything to disk *now*", because our filesystems are not that great). If you're running it async, then you get exactly the same semantics as a plain write. The kernel already guarantees that stuff will be written to disk within n seconds, with n a tweakable parameter that's important for power saving. I guess I just don't see the advantages of moving that to a million per-app settings, all using an inappropriate interface.
If the goal is to reach a point where we can throw away a lot of data instead of flushing it to disk at shutdown, then this approach is making a classic mistake: it's trying to mark everything that *does* need to go to disk, and hoping that eventually everything will be marked and we'll be able to flip the switch and throw everything else away. The better approach is to mark stuff that isn't important, like some fcntl to request "power-loss semantics" for writes to some file; then you could get some win immediately, and expand it incrementally over time.
I doubt this is easy or important enough to actually get the coordinated effort needed to implement it, but that's how I'd do it...