@ych - thanks for the suggestion. I can say that many things are considered when designing a new platform. For day 1 launch capabilities, the feature definition does contain elements of backwards compatibility, but more importantly, the significant number of new capabilities are what draw my attention. Moving from a compiled solution into a scripting solution will come with trade-offs and in some cases, hard limitations on what you can and can not do. I am excited about the trajectory of the new platform and am glad to know there is some degree of interoperability with the prior generation solution that served the market for 20 years. As a user community, if there are feature requests - we need to get those communicated and this is a terrific forum to do so.
Look at the recent wins -
We want an IR Edit software that works with computers from this century - DONE (IREdit 2)
We want an IR capture device that is smaller than a shoe box and can not be used as a weapon - DONE (IRIS 2)
We want software that is natively cross platform - DONE (IREdit 2, Muse Automator, VSCode)
We want another language option because my team does not know Netlinx or Java - DONE (Python, JS, Groovy)
We want a small POE automation control platform - DONE (MU-1000)
We want a faster boot time after code transfer - DONE (thanks scripting!)
Two similar variable names for the same ThLv series both flagging duplicates sure sounds like a define oversight. No joy using "FIND IN FILES"? If you ultimately can't locate any other use of the variable name, what's stopping you from using a new variable name and let these go?