If I remember correctly, the problem with this EXEC/version was that people forgot to add a GO at the end of the stored procedure that was just above the EXEC/version statement, and therefore it became part of the stored procedure itself.

One quick way to fix it would be to retrieve the current pre-execution of the script and compare it with the version post-execution. If they are the same, then it means that either something went wrong or someone didn’t properly version their script.

Well, yeah, in most cases it is detected on test database. What’s more, a programmer who prepares the script should *normally* not commit to source control any script with syntax errors (so it should be tested on his local db even before the test one). The probability is relatively low, but it depends what you put in the scripts.
In our case, as you may know ;), at the end of each script there is an EXEC statement responsible for setting script-related functionality’s version on the database. Many scripts may be executed by some external application (e.g. sqlcmd or C# code) and this issue (or its consequences) may be hard to notice/detect sometimes even on local/test db.

It just surprised me I couldn’t find any other “T-SQL solution” for that.