Not to rain on your parade, but this has been suggested before.
The problem with this approach is that the CADENAS models (if I recall correctly) have features but no intelligence. No constraints, dimensions, etc. Unless you have those, there's not much benefit over a dumb Parasolid.
However, aside from this, the problem is not with building a model in the old version of SolidWorks. The problem is correctly analyzing the model in the new version and translating its feature definitions back to the old version. As SW is updated, not only do new features get added to the software, existing features get changed/improved/etc. Along with these improvements comes more/different parameters that define the feature. Just because API is always backward compatible does NOT mean that old API can analyze and get full parametric feature info on a feature created in the new version. If you use old API to read in feature data, you will only get parameters that were available in that version. A lot will be missing and the resulting rebuilt model will be garbage. If you use new API to read in, then you need somehow decide how the new definition data translates into old API that doesn't have that same definition data. This is impossible without knowing design intent.
My (completely unqualified) estimate: 5 programmers, full time, 1 year might you this functionality for most of the basic solid functions. No surfaces or any other fancy stuff. To recoup development cost, it will be very expensive. For such expensive software, users will expect perfect functionality with their terrible models. Any features (even really basic features) created in new SW will have a high probability of creating garbage in old SW due to different definition.
Anyway, good luck!
Baren-Boym tried this. They even got as far as announcing a product release. They did not get as far as an actual release (to my knowledge).
It's more difficult than it seems. The underlying code for even simple features grows with each release. How do you make a backward step into features that no longer exist?
When I first saw your post I was a little confused. After reading some of the responses, I realized it would probably be better titled as "Backwards Compatible Tool".
I spent about a year writing a program that could successfully translate most simple to medium complexity SolidWorks part (SLDPRT) models from newer to older versions with the intelligence completely (or almost completely) intact. Download demo here. The demo set isn't real exciting; the program can do much more, such as translating about 90% of the SolidWorks Essentials training files. Of course, I'm aware that translating SolidWorks' "ideal" training files and translating real-world customer files are two different things.
I'm not sharing details about architecture or my intended business model at the moment, but I will say that my approach overcomes many of the concerns that have been expressed over the years concerning such a program / business. I demoed the program to several notable employees of SolidWorks Corp and they were impressed.
The question is asked, "How does your program translate <insert very complicated feature or some feature that didn't exist in a previous version>". The answer is, the program doesn't. But that's OK. My question is, "Can a program that translates X% of all scenarios still be useful (and profitable)?" The purpose of the program isn't to translate every file in existence. The purpose is to help as many people as possible overcome the interoperability limitations in SolidWorks.
I last touched the program approximately a year ago. Since the project was entirely self-funded, I had to return to consulting for a time to keep the bills paid. I am hoping to return to this full time in the coming months. I am open to investors, so if you have any interest in partnering, please contact me.