Yes, also one similar build
Revit 2023.1.1
Dynamo Core 2.16.1.2727
Dynamo Revit 2.16.1.6510
And yes, i do have the DynamoIronPython package installed.
I have noticed that the name change happens by no action at all simply time.
Open new workspace, place custom node. Edit Custom node and wait. After around 30 seconds it renames
Hello all - We have now a reproducible way to do this internally and have filed a task to address this for the next Dynamo release (2.18). A big thanks to you all for pointing us in the right direction for this 
It seems to be a workaround to immediately do a save-as to the node after opening a custom node for editing.
Edit: NO
Even editing a DYF with nothing else open, the DYF will rename itself to backup.dyf
What is a current workaround except wait for a repaired Revit update?
Thanks Sol for your, and your teamâs efforts!
I second Andreas request for a Hotfix pretty please!! 
The workaround I am using at the moment is to take a backup copy of my .dyf before opening for editing. After i edit I do a save-as to a temporary location. After saving the file I manually edit the .dyf file using text editor and replace the updated Uuid with the original Uuid from the backup i made. This allows me to copy the new node into my package location and existing .dyn files still recongnise it as the same node.
To be fair I only use this locally in our internal environment since I donât publish my package Online to the package manager. I donât know what affect this would have in your published packages?
Thatâs a clever hack. Doing an immediate save-as after opening the DYF seems to be needed, too.
Edit: I tried that, replacing the Uuid and changing file names but it didnât work for me. Also, the nodes come back to be all on top of each other.
Weâll explore this, yes. It depends on whether or not Revit are going to release a hotfix, so we need to talk with the teams responsible there 
So there wonât be a fix until the next Revit 2023 update? We cannot really update Dynamo for Revit separately, anymore, yes?
Is there actually a workaround until then? I am updating many graphs from 2022 to 2023 and it requires editing DYFs.
There is a way, yes, as you can see in this post: Error - specTypeId is not a measurable spec identifier? - #17 by scott.tomlinson
Technically and officially we donât support this behavior as itâs not been tested, but theoretically it should cause no harm. Itâs a use at your own risk kind of thing.
Note that the fix is not yet out, and we are targeting 2.18 for it right now if itâs not too complex
Hello everyone,
Has there been any update? Has the problem been resolved?
Iâve been experiencing the same issue recently.
Iâm using Revit 2023.1.3 and Dynamo 2.17.
Thank you!
@solamour
adding that i experience this behavior on Dynamo Core 2.17.0 / Dynamo Revit 2.17.0
We have fixed this in Dynamo 2.18, which should be in Revit 2024.1
@solamour I donât suppose youâd have any insight into whether an updated dynamo will make itâs way into any new Revit 2023 updates? The slow moving cogs of large business have meant we wonât be able to get onto 2024 for a while yet
There have been some amazing dynamo leaps but cant take advantage of them due to being stuck for now on Revit 2023
Weâre looking into that now For the Dynamo updates we rely on Revit patch cycles, so we need to piggy-back on top of that.
The tricky thing is the matrix of stuff that Dynamo touches and testing (i.e. Geometry kernel, base Revit APIâs, Analytics tools, DLLâs that conflict with other addinâs etc.) meaning that we donât release features backwards but rather only target bug fixes, stability fixes, performance fixes, memory leaks etc. in ways that are 
verifiable and tested.
Itâs a tricky balance, because we need to be confident that any fix doesnât make things worse and the further back the Revit version, the more out of sync it becomes.
#lifeOfSoftwareDevelopment #theJuggleIsReal
Yeah, thatâs fair enough! Definitely appreciate your work, and thanks for looking into it
