The issue seems to be that many C++ plug-in developers statically link to the C Runtime, and this is the source of the limitation. I assume from this that plug-in developers tend to statically link to the C Runtime (which embeds it in the plugin) rather than depend on installing a version of the Runtime on the client system and dynamically linking to it (and of course needing to redistribute it to client systems).  Plugins that have an installation package can include a C Runtime, but for developers that just ship a Dll it's obviously easier to have just the Dll without any other dependencies or instructions to find a C runtime.
 
The C runtime has often been a pain to install (Microsoft's issue) and the response by many developers has been to statically link (the developer's problem) to the runtime rather than deal with getting the runtime installed on client systems.
 
(I wrote a book on this in another life, seems an age ago now, but it's still on Amazon, lol)

I don't know about any VST limit. But I do want the CPU that can run with so many VSTs it exhausts the number that can be loaded. That is some CPU! 

Quote from Craig Anderton's post above:  "Well, same here. If it's always been around, it seems strange people are just picking up on it now. I wonder if this affects ProChannel modules as well...probably?"
 
I am not sure if it does effect ProChannel, actually - I thought Sonar had been doing installation of C++ run time libraries since X2a, and likely dynamically linking to those modules, as it wouldn't run without the Windows 7 Service Pack 1's included C++ run time libraries.
 
If Cakewalk development DID specifically, and properly, choose the dynamic linking path for those modules, and it DID bypass the static limitation, then I'd have to say WELL DONE, Cakewalk.
 
In any case, I have not heard of or seen any indication that Sonar's ProChannel components suffer from any limitation, so WAHOO!  (too be honest, I don't ever flood any projects with enough plugins to run into any limits that I am aware of.  If the Beatles could do it on 4-tracks, and sound good 40 years later, I think it likely more important to focus on the quality of the song.  And, even if you put Yoko Ono in the finest studio on this planet, with current technology, and all the plugins and outboard gear available, and the finest engineers, she would still sound like a cat snuggling a porcupine).
 
Bob Bone
 

ProChannel has one major limitation - You can only have one PCEQ display expanded at a time

Its a really bad idea to statically link to the C Runtime library. Not only does it bloat the memory space with redundant copies of the runtime libraries it can also prevent efficient use of memory by circumventing caching. Additionally it prevents Microsoft from updating the runtime via service packs. i.e. if there is a bug or security flaw in the C runtimes it can't be fixed in the future unless the plugin or executable is built with the new runtimes. 
 
Cakewalk has always dynamically linked to the runtimes (for SONAR as well as all our plugins) and we keep up to date with the latest compiler technology. This is why you always see the msvcrt installer included as part of the SONAR installer. While this has had its share of problems its a far better solution than vendors statically linking this in.
 
BTW the limit due to this is not as extreme as it may seem. In SONAR you would have to have at least about 64 unique plugins that statically linked before you saw a problem, so pretty unlikely I would think. Also multiple instances of the same plugin do not count since the dll is only loaded once. We routinely see hundreds of plugins used in projects and most people tend to use similar plugins like eq's and compressors on tracks rather than different ones per track. In all the years that SONAR has been around I've never heard of a complaint that plugins don't load so it seems like a pretty small corner case not worth worrying about.
 
 

Nuts! I was going to use 65 plugins in my next project. Well I guess I'll have to forget about that one.