Can't you have a scratchpad area that's read only dedicated to the GPU/games? The file system duplicates necessary game data onto that partition and you can ignore file access responsibilities, because it'll just be flat out "anything can read, nothing can write", and the GPU can read whatever bits it wants. I presume technically that's feasible but not practical due to existing legacy structures imposing a certain system-wide way of doing things.
I think you've discussed several of the bigger points in why this doesn't necessarily help. Just to further elucidate:
Creating a sub-partition means you have to re-partition your existing storage as a function of installing your GPU. Obviously not a problem for those who are building a new-from-scratch PC today, however a bit of a pain for those who are upgrading their existing GPU, or perhaps they're updating their version of Windows and/or DIrectX12 to support this new DirectStorage Partition functionality. Repartitioning an existing disk is entirely feasible, but also makes assumptions about the free space available on your storage, and then we're back to managing unique storage just for your game data, which will just be duplicate data from your "main" partition(s).
You also hinted at another curious challenge: we need to be able to write data into that partition, but it also must be block-mapped so the storage driver knows how to translate GPU reads into the specific blocks of storage where the requested bits and bytes are stored. We are functionally creating another file system, fortunately the GPT spec already provides for this unique type of workload. However, the act of moving data from "main" partition(s) to this new partition will require some modicum of translation, and of course you're blast-read-and-writing to the same SSD as you go. This ultimately results in bottlenecking the process to half of what a common user might expect when reading a disk benchmark.
Additionally, creating a unique partition inside of the existing main storage means the space will be very constrained, the worst-case example would require a pre-processing step (wipe GPU partition, transfer + translate data from main partition to GPU storage partiiton) every time you load a new game with new assets. And what do you do with games with assets that are enormous? Devs would probably use the GPU storage partition as a cache of sorts, holding the most frequently used assets, and then keep the more unique stuff in the main data partition. Now we have a hybrid approach, with hybrid performance pitfalls and caveats and code challenges for the devs again.
Finally, protecting that partition from malware is going to be of high interest. If you simply create a partition where "anything goes", then it's going to find itself a fast easy target for malware to hide. Now we have to think about how EDR solutions will protect this area, to ensure it doesn't become a breeding ground for nasties.
And for what? The performance gain would be arguably minimal compared to what DS can deliver today. There are still two trips to main memory in the current DS implementation; this might remove one or both. And while removing these steps might yield incrementally more performance, it's going to be hard to argue the squeeze of creating a whole new partition type, security methods, data cleanliness and management processes, and requirement to "stage" game data before it can be effectively used outweighs the arguably tiny enhancement to fetch latencies and additional loading throughput.
