We did some usability testing when we were developing the Conditional Disable structure. That structure was meant to let you pick between alternate chunks of code, not impact the code itself. The first design of it did not add synchronization to the diagram, so if there were parallel chunks passing through the same Conditional Disable, they were free to run independently without syncing up at the borders. We had multiple users tell us they found it confusing to read the diagram, so we changed the nature of the node.
Fabric is right -- there is a purely decorative frame available. It doesn't behave like a structure node -- it just overlays the code, so when you move it, the code underneath doesn't necessarily move with it. And auto diagram cleanup has no idea what to do with it. But because it is divorced from the code, it seems to read better to many users.
The suggestion is a reasonable suggestion, but I think it would need to be fleshed out with details -- what would users propose as a visual for the bounding box that makes it clearly "not a structure node"? Do you want it to be able to cross the border of other structure nodes (for example, one frame might contain a portion of code from two or more loops)?
Refining these details might help us evaluate the feasibility of such a frame.
I would like the objects grouped together so that they stay grouped when you run diagram cleanup, and similarly be able to exclude the structure from diagram cleanup.
To keep it simple, I would say no crossing of borders, but containing parts of separate loops does sound like an interesting idea.
I hadn't though of the confusion that an asynchronous box would cause. If that turns out to be a big issue, then flat sequences already do what we want.
Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.