@john_pierson I think you’ve got a major uphill struggle since you depend heavily on Dynamo and Revit APIs and with the myriad of changes occurring not to mention the coverage your package has over many aspects of the various APIs your options are limited.
In all honestly, I would let go of the idea of having one package to serve them all and do what say Clockwork did when 2021 changed the unit types, and release a Version 2024 of your package. The reason why I think this is the best option in your case is because of a major clanger (IMO) from the Dynamo team (which also affects BimorphNodes - I’ll explain more next) which means, even the solution I suggested on Twitter wont work. It does work for Revit however. The next problem is the fact your time isn’t free yet a lot of time goes into package development so maintaining two versions is going to be a nightmare.
The clanger BTW is the fact that Dynamo uses longs - a value type - to represent represent ElementId’s - a reference type - in the Revit API for 2024. In previous versions its an int and therein lies the problem. This isn’t a problem so much if its internal in your code as there are workarounds, it is an unsolvable problem however if you have any nodes which return ElementIds from Dynamo types since its a type change rather than a change to a property in the type (i.e. Revits ElementId using a long instead of int in 2024). Therefore, there is no way to handle this problem, unlike Revit API where dependency injection can be used - its what BimorphNodes does.
I suppose you could box the value meaning all outputs returning ids would need to change to the object type but that brings with it a type change that will break all graphs using your previous version and create new problems in the future as the type is ambiguous. If Dynamo API had created its own wrapper around ElementId this wouldn’t be a problem. Nobody’s perfect. In BimorphNodes, this problem affects 1 node and my plan is to depreciate the node in the current version and hide it in future versions since other nodes can provide the same result - washing my hands of the problem essentially - and this is why packages with lots of dependencies on the Dynamo APIs cant do this and why releasing a new version is most likely the only option.
I’m still going to publish a article explaining in detail with full implementation details and code snippets to expand on my twitter post, I just don’t know when this will be as I’m snowed under with project work at the moment. I’ll aim for first week of September. You could solve a lot of problems with bar the issues with the Dynamo APIs - the alternative is to remove any node returning element Ids or anything else which is a reference type in Revit but a value type in Dynamo and weather the storm of breaking changes it will create. At least you can stick to maintaining and publishing 1 version which is best IMO irrespective of the shortcomings of the package manager.