Correct me if I wrong, but proposed by NI interconnection schema inside any DAW is the following:
DAW <-> Native Kontrol (wrapping VST, proposing NKS for better integrations) <-> NI Controller
In that respect, Native Kontrol is a "DAW inside DAW". And in case of Cakewalk that is going to be:
Cakewalk Sonar <-> Native Kontrol <-> Cakewalk VST.
So, OP propose Cakewalk spend time to make Cakewalk VST NKS friendly, while NI has no known plans make NKS Sonar friendly. Nor NI had any plans make there controllers directly Sonar friendly, Cakewalk schema:
Cakewalk Sonar <-> VST/DXi
|-> Hardware controller (open source SDK for deep integration with Sonar is published years ago).
In that schema, controller operates Sonar (mixing, transport, menu, etc.) as well as plug-ins (VST, DXi) throw Sonar (moving focus to different plug-ins, changing plug-in preset, changing plug-in automate parameter throw ACT or directly). Sure that schema was not updated long time, so Sonar X+ features are not exposed in API, ACT has many bugs, etc.
But why Cakewalk instead of spending time to lift there own (not bad designed!) Controlling Schema in Sonar should invest into supporting third party controlling schema in there VSTs?
If NKS API is better than VST automation/presets API (which is not proved by now) AND (!) it is open to be used by DAWs as well (so, Cakewalk can implement "server side" NKS inside Sonar and load NKS enables plug-ins without NI wrapper), it make sense to ask Cakewalk support NKS in Sonar and VSTs. Otherwise, NKS is just a marketing trick using "heavyweight" power to force VST producers help NI to collect more money for there "exclusive" boards (which as a hardware are not so exclusive).
I think I have explained my point.