Probably only Mathworks could even possibly answer that and they may have zero interest in doing so since the Borland compilers are now so ancient and unsupported.
Borland C++ was developed with a very early version of C++ before the ISO Standards were released and as such has some unusual and incompatible syntax features that undoubtedly Polyspace Bug Finder will detect as being non-standard but will not have a way to customize that is valid source code for the specific compiler.
I cannot imagine that Mathworks would spend resources on making such extensions for such an old and obsolete toolset.
About the only possible reason one can imagine in continuing development with Borland tools is support of a legacy system, but even there, at some point if it is going to be a continuing product/requirement it'll be a better investment to move to a current and supported toolset.
I have some experience in the area having kept an old system going with a system ported from the old DEC VAX FORTRAN compiler to Digital's Visual Studio Fortran compiler running on '386-vintage PCs under NT4. This package is still running at some 30 power plants, but has not been touched now for almost 25 years; the utility company has a warehouse full of old desktop PCs they hang onto solely to be able to swap out any of these systems when they die...
Fortunately, the FORTRAN code is very standard F77-vintage and could be converted to a modern compiler if it were to be decided upon to do so; unfortunately, depending upon just what features are being used in the Borland C++ environment, the transition ot a current C++ compiler may not be so simple. It's been a testament to the original code design that the plant models are complete and user-definable via input configuration and parameters data files to handle the plant modifications to date. The update was to add a module for the scrubbers that weren't around at the beginning -- but as noted that's now almost 25 years ago and there's been no additional changes needed.
If, however, if the need were to arise to rekindle development of the code, it would then be time to move into a current toolset rather than continue to have to support the legacy system. Only you and your management know the real constraints in your case, but my opinion would be it is time for a serious reevaluation of the path going forward.
