Are we overthinking this? Once the BIOS thinks it's storage and IO.sys thinks it's storage, how much more do we need to do? If Disk Manager will assign it a drive letter and run it as that drive, everything else should fall into place. Treating it as a 5th or 6th level memory cache is more involved, but not so complicated as to be untenable. That's what drivers are supposed to do. Even an app that blurs the lines, in a usage paradigm, should not be that hard for the MB manufacturers to figure out and implement. Once a standard is set, it's just 1's and 0's.
Unfortunately it's not that simple. Persistent memory needs to be ACID compliant, and new programming semantics are required to write good code that ensures that the data in PM is handled with all the protections that block mode programming has had for some time now. Just because you can read it with a "load" command doesn't mean you can "store" it as you do to DRAM. I encourage you to take a quick look at the SNIA PM programming model site (link above). The good news is that the work is well underway by both Linux and MS.
ROFL. The document you referenced goes into excruciating detail for 85 pages on how to accomplish exactly the usage cases I outlined. What it doesn't do is break any new ground or describe any major shift in requirements or capabilities that don't already exist. Make no mistakes. Either the device can be treated as a drive or memory or even an SSC, or it is DOA in the consumer space. Users don't want to have to do anything, but assign it a drive letter or, as memory, plug it in and automatically load a driver. Some power users may be willing to manage an SSC, but, frankly, if I have to do a lot of management, why do I want it? The entire point of memory as storage it to treat it as storage. The entire point of persistent memory as memory is to treat it as memory. The case for an SSC is to set it and forget it.