Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

I think most CAD software predates C#. And also predates Mono (which means they would have been non crossplatform).

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

Sunk cost fallacy...

A good reason would involve comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.

Depends on the company, I think AutoDesk has some products that you can interop with C#. Others, like my company (e.g. https://www.bentley.com/en/products/brands/openroads) use a mix of C++ and C#...many of our power applications sit ontop of a C++ platform for graphics, element storage, etc but a lot of the business logic and UI are in C#.

C# is more than suitable for a robust graphics application however, you will need to care more about memory management than a typical C# programmer may (e.g., the upcoming language feature of "ref returns" is a big deal to us, but at the //BUILD conference this year it kind of just was shoehorned into the C# team's presentation).

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

Sunk cost fallacy...

A good reason would involve comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.

... and that cost would be hundreds of millions of dollars.

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

Sunk cost fallacy...

A good reason would involve comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.

Disagree with this application -- at some point its been far too long since the train left the station, the train's designer died or retired years ago (no one really knows), the conductor and engineering staff have completely turned over 5 times, and no one remembers any of the bugs that were squashed into the tracks further than about a mile back.

Its almost never a good idea to go all green-field over your existing product when the product is large and complex, and when your user-base is entrenched -- and especially when they're entrenched in your product's quirks and bugs. You want to talk about a nightmare... reaching feature-parity with a large and complex product is a nightmare -- but reaching bug-parity with the kinds of bugs people come to rely on (which, by definition, stayed around long enough to be relied upon precisely because no one could ever figure them out) is more than a nightmare, that's some Hellraiser shit right there. You know that weird for-scope bug from Visual C++ 6? The one with the option to turn it back on in every version of Visual C++ since it was fixed? There's a small set of regression tests somewhere in Microsoft that make sure no parser change or bug fix messes with that, and there's an engineer who's job includes making sure those regressions never go red. 20 years later that's still earning someone their bread, because the cost to the business is less than the cost of losing clients who can't or won't fix their code, even though its a good idea. And that's a trivial example.

Generally you would only make that kind of leap when the market forces your hand -- In recent years there's been a good deal of effort to get off of old systems written in COBOL and Fortran that very possibly run on old hardware you can't buy any more (and even repairing is difficult and costly), but mostly because there aren't any new COBOL and Fortran engineers who understand the intersection of those languages, and machines, and operating systems, and they can't persuade enough old coders to come out of retirement and into consulting -- the ones they can convince are A) billing at rates somewhere between a-charity-date-with-the-queen-of-England and who-wants-to-hunt-the-last-African-rhino, and B) are not unlikely to drift away at any moment due to death or dementia.

That sounds an awful lot like comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.