i think you're misunderstanding this again. part of this is we're talking past each other in confusion as to model elements, the data representing them, and the conceptual object that they represent.
no, the guid doesn't change, however what constitutes the extents of the room changes. if i delete a bounding wall i expand the area of the room within that phase. the room is calculated in 3 dimensions- but it's actually ignoring the 4th. calculating it in 4 becomes significantly more complex. that's a change in our conception of the room across our workflow time, but it's a change to the elements contained within the room, all that happen within the same plane in the model.
phase created and demolished is time. from a standpoint of the database, the wall will be there and won't be there depending on how we choose to view it. it's not dissimilar to Schrodingers cat except that conceptually we know it's there as a data line item. when we choose what phase a view is set to we're in effect choosing to look at the movie at 45:32 into it. all of the data is on the DVD, but we're just looking at one particular frame. in thinking about the "coordinates" of the model elements, phase is just a differently demarcated dimension which we can locate objects in.
different elements have different bits of data attached to them, and we don't want to accept impossible or logically invalid pieces of data. thats why sketches become invalid when a line within them is adjusted to a 0 length. several logical layers deep, revit is refusing to make something that can't logically exist, and it warns you it's going to delete your ceiling because the sketch has become invalid. even though you could set a line length theoretically to zero within the database, revit tells us that is not a valid input. you're advocating setting a value at a level at something that becomes remarkably complex and could trigger recursive loops.
lets say we have room A and B adjacent. if we delete the wall between, we'll get a warning that we have multiple rooms enclosed, not a terribly complicated calculation. if the wall between were to be demo'd, revit suddenly needs to decide if A and/or B should be demolished based on the same logical difference, that they are both in the same space. revit could choose to demolish either, but realistically it should demolish both at that phase change. now, if we want room B to just expand, suddenly we have two different extents for room b. one set of data for it in phase 1 and another in phase 2, some elements of which may be shared, or not. by overriding room B to be demolished later, suddenly we need 2 different complete sets of data for room B, which arguably should be a second GUID. this comes back to moving an AC unit. you demo it in one location and the relocated unit gets a new GUID. if we wanted the adjacent room C to just persist across the phases without any change, the calculation required to "see" the extents of the room will look at each wall, and note that one data point for each wall has changed, specifically the phase that it's present in. it will then need to recalculate that room, and since every thing in the room changed, we still need a second GUID for the same room in the new phase.
this really is more into the realm of physics logic puzzles than architecture, but i've explained how and why revit could behave how it does (without seeing the actual logical code it's using it's impossible to really know) and why that behavior makes sense, and ensures the model behaves as expected. Now, there's a herd of things that autodesk has done to fuzz up revit and make things behave in ways that aren't as mathematically accurate, but assigning multiple relationships to the same GUID seems like more problems than it's worth. -- that said, similar things get worked around people assign the same mark to different walls that have the same structure but different cleanups to accommodate graphical and construction differences that the field only needs to see as gyp wrapping or not.
