Currently what happens is the name of the track becomes the name of the soft synth, like Dimension Pro 1. Respectfully, that tells someone very little about the tone and typically results in the track being renamed. So, in the name of process efficiency, how about defaulting to the name of the patch for the track name? And if there's such importance and listing the soft synth, how 'bout appending it to the name, but in abbreviated form? Like Sitar (DP) or Sitar - D Pro.

Nice!

When you did envision the patch name being written to the track name?    I have a habit of previewing many patches so would not want the track name to be dynamically tied to those changes in real-time.   Just a pre-vote question.   

It could get interesting with program change data embedded in a MIDI track. While DPro does not honor program change data, other synths do.

Well, while you're are it, why not save the data for the patch as a file associated with the track? It would allow one to recreate the patch in any other project or for aiding in project recovery after a catastrophic failure.
 
Regards,
Dan

apply the patch name at bounce, split into clips to honour the program change's new patch name

the only negative thing about it is that somebody (including me) often calls the track so it defines the function of it, not by patch name. e.g.: Sparkly background arpeggiator or Sad Pad or stuff like that. If Sonar dynamically changes the name of the track every time you change patch, you end up having to re label the track when you make an instrument change, and that can happen several times during the arranging phase of a tune.
It would be super helpful, tho, to see what the OP proposed somewhere on the channel cubase - style (I think?)

have an option to auto-name the track on/off

Not sure how this would work for plug-ins with multiple tracks.

Not sure how this would work for plug-ins with multiple tracks.

some kind of delimiter-per-track? concatenating the clip name isn't a new thing code-wise, but indeed, the more inputs the messier and less useful the output, so probably just always use first track only... although thinking about this now, there could be use for a full-on "normalise" (in a data sense rather than audio-level sense) process that could take an input midi clip, and output multiple per-channel, per-(certain-)event, new midi tracks containing the spilt/trimmed midi clips with associated labelling, like some of the cal scripts do... the possibilities are quite broad but how useful would it be? 
 enable sonar api to powershell scripting