I'm going to presume that you have sound reasons, whether business or otherwise, to do this. It seems simpler to me to pull the appropriate versions of your test code from the source repository (you do have your test code in a source repository and flag the versions, right?), but anyway...
I see two main options here. One is to include version detection and an internal listing of features per build. Benefits here include making the test simpler because if the version list says feature X isn't part of it, the script never checks feature X, and the presence of a 'feature oracle'. Drawbacks are that it's more complex to implement and maintain, since the feature/version matrix has to be correct and up to date or you could have features not being tested (if the oracle says the feature is from a later version or is missing the feature entirely) or tests failing (if the oracle says the feature is from too early a version).
The other is to build feature detection into your scripts instead: check for the existence of the link to feature X and act on it only if it exists. Advantages include - if the feature is there it will be tested, tests will never fail on trying to exercise a feature that doesn't exist. Disadvantages include - this will be slower because there will always be the necessary checking time to determine whether the feature exists, you won't know if a feature is missing from a version (unless you use both approaches, which of course gets you all the advantages and drawbacks of both).
Regardless, changes to application objects will get you some pretty ugly code: instead of pulling versioned code that refers to the specific object, your script code will end up with a decision tree based on version or whether the object can be found under any of its known names.
I'm honestly not sure that the advantages of having a single branch and version of your script codebase outweigh the disadvantages of this approach, but if I had to, I'd approach it with a hybrid approach as I described above.