I’m new as well to speckle and trying to wrap my head around it so I can communicate to my project team (and evetually my firm) .
Since you asked, Im going to ramble what I’ve been thinking about how it should function
I think the expected update behavior comes down to the intended audience. I envision a team made up of a few people who understand speckle on a deep level, but the majority will not want to understand or need to understand it. they just want it work as simply as possible.
As I’m thinking through this project, and trying to plan/strategize how we approach streams and branches and how they are set up, what I keep coming back to is simplicity & truth. Ultimately i think the most important thing is that everyone is confident that they are using the most up to date geometry (data). There is no confusion as to which version what stream/branch i should be referencing. eg: if Im in Revit, I have the most current landscape and façade model referenced in from Rhino. And if im in Rhino working on the facade, there is no doubt which Revit interior model i should have loaded in as I work.
What is great about speckle is that if I have loaded in a stream, it will notify me that the stream has been updated. However like the OP mentioned, it doesn’t quite work like I expected. In Rhino, it isn’t that hard to know that I need to delete the entire layer structure out to remove any old geometry when I load in a new. A small negative about the approach of having to delete the previous commits as i bring in new ones is that i might have accidently modeled something on one of those layers (or copied geometry to iterate on) and then it would be gone since I bulk deleted those layers.
however, in Rhino, I would think it would be more intuitive if I have chosen to have the ‘latest’ branch linked in, that it would update all that geometry that was in the already existing layers speckle created. if for some reason I want to know what has changed, or reference something from a previous commit, then I would load in that specific commit, and it would add in a new layer structure with that specific commit. but the ‘latest’ layer structure would always remain unchanged and would be the most recent receive i have done.
Regarding breaking references to grasshopper scripts, i would expect grasshopper references to break regardless of how its updated. I would probably structure what I’m sending in to speckle in a way that I would use a ‘Human’ ‘Dynamic Geometry pipeline’ to grab things from that specific layer.
The biggest issue that I’m wondering/struggling wrapping my head around is actually Revit and how bringing in rhino geometry into Revit seems to work. This concern comes from me messing around with stream branches. If I have 2 rhino branchs like:
Then if I choose to load in /facade/option1 into revit and then want to switch evert thing over to /facade/option2 then it seems like i need to somehow select manually all 100s of things imported for /facade/Option1 and delete them? there is no way to remove what speckle has brought into revit.
(Or if for some reason the stream connection is broken, then I’m left with possibly 100s of generic models that I have no idea how old they are and if they are correct or actualy the mot current /correct geomtery. )
It would be nice if when i bring in rhino geometry into Revit that it gives me option to put them in a specific workset, or at least group them So if a user sees a group of a bunch of geometry, they would know that its from speckle, and if it seems wrong, i can delete the entire group quickly and reimport what I want. Or maybe even the option to remove that import from revit using the speckle stream plugin (all this could already be in there, so apologies if it is)
Like i said its about reducing complexity, and increasing the knowledge and confidence in the team that they are working with the newest/correct geometry.