I’m not not he product team so I can’t speak directly on this stuff, but I have enough indirect insights to help out. Some of this has been addressed, or is planned on being addressed. However there are bigger more involved projects which have to be undertaken such as the .net 6 migration - if that doesn’t addressed then we won’t have any Dynamo for the 2025 product line. That is a VERY big effort (sort of the AEC equivalent of rebuilding your largest project from scanned PDFs and no content library to work from) and as such some other things may have to take a back seat for awhile.
Gavin was spot on that the github is an ideal place for many of these issues (and you might consider a support ticket for the Dynamo player issue with the second monitor). Generally speaking ‘it’s broken’ means a GitHub issue for Dynamo Core or Dynamo for Revit would be good, and quality of life improvements can go to the wishlist. The roadmap is also a good place to put feature requests/improvements - perhaps even better as that gets some insight across Autodesk products (Civil 3D and Revit and Dynamo feedback can all be aggregated).
I’ll do my best to give some insight/solutions/fixes for each of the bullet points above - feel free to reply in kind.
There are a few ways around this.
- The post here has a tool to bulk update all graphs to convert your entire library. Updating python node in multiple scripts - #15 by jacob.small
- The Monocle view extension has a tool to adjust the sizing for the active graph.
- The graph migration assistant has a beta of sorts which you can try here: GitHub - DynamoDS/DynamoGraphMigrationAssistant
Text in the library is now zoomable as of 2.17 by holding ctrl and using the mouse wheel; upgrade to 2024. The hierarchy tree is actually insanely useful in using, learning, and teaching and from what I can see hasn’t changed since the days of yellow nodes.
I can’t say I’ve seen this; do you have a Revit add-in or View Extension causing a conflict or a package with the wrong version? Last week I did see some significant slowness when Dynamo/Revit could not authenticate, so you may want to confirm the issue isn’t resolved by changing your network.
This is in the backlog with an internal ticket for producing it; however I would expect it to be a lower priority as it has a work-around (set the run mode externally prior to opening the file) and has less impact than the other work underway (see the roadmap). If you need a graph to bulk set the period timing let me know and I’ll see if I can put something together later.
I logged the github issue for you here; not sure how this fell through - thanks for bringing it to the teams attention.
I can see a lot of added issues by doing this; where in the group would the nodes be placed? What if that pushed the limit of the group or was on top of another node? Likely best to expand it before dragging into the group, which is the intent at this time. If it’d be a huge benefit for you please outline how in the roadmap or wishlist.
Might be a resolution issue - can you submit a github issue posting a pic showing what you’re seeing? My monitor resolution is set to “starting to go blind but was too stubborn to get glasses before immigrating and now has to wait a bit longer to get into the healthcare system”… 
I thought of this as a feature instead of a bug, but with a coming build the text (and I believe the icons) change dynamically with the color of the node. Feel free to add this to the ellipse size issue as an add-on when you submit that.
I haven’t seen this - is there any chance you had the group selected as well? For the crash, were you in Dynamo for Revit with Automatic run mode on?
I believe the intent there was to have it at that static size, but it is a good wishlist or roadmap request.
I have only seen this be instant, and I’m already working with some pretty large graphs in 2.18; can you get a screen-recording and submit an issue to the GitHub? It may require some specific hardware and configuration discussions between development team members so that is a better route.
Can you post a pic and a graph showing what you mean?
Player has been updating a lot, but sadly this couldn’t be made into a persistent setting without delaying all the other benefits. As a work-around I added a tool to the bulk updater to automatically rename input nodes with a numerical prefix to ensure alphabetical sorting was always respected. Ideally something like that would make it’s way into core or a view extension, but I think even better would be a way for graph authors to define the sort order with a degree of control which doesn’t require setting the name in a particular way, or toggling a setting in the player interface.