That’s the part that has been taking the longest and has required the most testing. We’ve put in code that integrates into WinMM as a MIDI driver, and then forwards everything to the new service.
In that process, we’ve found different bugs in apps out there, where they may use WinMM in an unexpected way. So getting this right is important. This feature is enabled in the February Canary Insider Build. I also have a couple videos of it in action here:
Here’s SurgeXT, without any code changes, using the new services. A MIDI 2.0 device is sending MIDI 2.0 messages, which are translated to MIDI 1.0 in the service and sent to Surface XT
Here’s REAPER using Network MIDI 2.0, over WinMM
WinMM apps won’t get all the new MIDI 2.0 features, but they’ll get multi-client MIDI, which is nice 
One reason for apps to move to the new API is they get much better device add/remove/update notifications than WinMM ever provided, and no more port numbers. Devices are identified by strings that are more reliable than an index.
The new SDK and Services also provide a unified view of endpoints, with one API to use regardless of MIDI 1.0 or MIDI 2.0, Network, app-to-app, loopback, (bluetooth, eventually, RTP, possibly), etc. Without the WinMM 32 character limit, it can also provide the endpoint names that the manufacturers wanted us to use.
You can see a number of different endpoint types annotated in the MIDI Console output here:
Pete