Yeah. This is one of the reasons the teams have a pretty significant process for deprecating things, and does what they can go give us as much heads up as possible. The hard part and something that is perhaps unforeseen in all of this is that the API was written back when the intent was that you’d have a version of your automation tool for each Revit release, building it uniquely for each Revit version. Some of those builds would be exactly the same, but others would requier some legwork, which generally wasn’t bad when you had a year or more worth of notification that the change was coming.
Then Dynamo came along and ruined all of that by allowing the same .dyn to run in Revit 2016 to 2024. From a ‘Dynamo for Revit’ standpoint the team is in fact building a unique build each year, referencing only one version of the Revit API in any build, but allowing migration tools to map stuff like “Select by ID” to push the API changes as they come, accounting for the 64 bit element ID change in 2024 without having to change your .dyn. But for package authors who’re pushing package build X to every user and expecting it to work… that just doesn’t seem feasible without multiple switches in your code, and even then it’s a nightmare. This is why we get stuff like the archi-lab versioning issues. Hopefully the team will come up with a good fix to this ever expanding issue. And if not we’ll get through this all by modifying each other’s code, which is the true beauty of the many ‘source available’ tools we’re producing.