Hi,
here are two possible examples of workflows for hidden wires, these are concepts in grasshopper which is a open source node script system for rhino cad.
and in the video at minute 11:00 hidden wires.
These are plugins from users who are confronted with large node groups.
Having Set nodes that write to some local state could potentially be confusing, because you couldn’t copy the Set node to write to the same variable in multiple places.
Is it possible to have something like const local variables, that could be set once per function call, and trigger an error when they aren’t?
With more and more complicated node system, it gets closer and closer to “real programming”.
IMO introducing simplest fundamental programming concepts, and using conventional naming for things, in the long run is way less confusing, than inventing unique terminology and unique concepts.
Taking some ideas from this thread, I have visually updated the instantiated nodes proposal. In this example the instantiated node is Distribute Points on Faces, as you can see the connections of one node are indicated in the other and the values are identical. Selecting either node should highlight the frame of both. As there are two instances I have indicated it with the number 2, and because it should be possible to make the nodes unique I have also added a dropdown menu.
As I have commented previously, this already acts as portal, but instantiating groups could act as a collector and at the same time process information.
The idea of hidden named noodles might be easier to read. Without selecting anything, one can see where portals come from, and where they are used.
I thought about portal-noodles for a while. My main concern is that current portals are indistinguishable, until a connected node is selected. One would have to go through all portals to get an idea of whats going on.
Thinking about it, it appears to me that it might be like someone looking for a snack … but he cannot find the fridge, because he walks around with a microscope.
As a user, I like much the idea of named portals.
Elegant, familiar, partially working - could be improved to be a global workflow and viola.
In case the (Noodleless?) Wireless Portal will get implemented, how about when selecting either Receiver or Transmitter, the other one would automatically get highlighted?
Like, always be highlighted in pair so you always see the link.
TBD whether to make a special type of highlight, or just keep the current one.
But I wouldn’t want this for the alternative. (dimmed/hidden noodles)
Someone raised this idea (or something like it) earlier in the thread, but I like the idea of there being an option in the overlay panel that when checked or unchecked would automatically add back in the noodle connections that portals would remove. Toggling the option again would go back to the elimination of the noodle lines or line segments. That way, if for some reason you wanted to quickly bring back the mess of noodles and the corresponding ability to trace one node to another visually, you would be able to do so.
This was where named attributes worked well (but also failed, when you rename an attribute).
In case the (Noodleless?) Wireless Portal will get implemented, how about when selecting either Receiver or Transmitter , the other one would automatically get highlighted?
Or, alternatively selecting the node would show hidden links again and / or highlight the first set of connected nodes (this should probably be implemented anyway instead of having the user follow the connection line of the node).
Portal nodes: this involves more work having to add two extra portal nodes, which would only add to the confusion, plus you still have to search through lots of nodes to find a matching name. This is not a good solution for single connections, not sure about multiple connections (which are not that common).
If this is going to be implemented, please support it for Python nodes as well 
perfection, you hit the nail cleanly on the head 
I would also suggest that when you click on a node, the wires re-appear to the left of the floating text. This will make it easy to find the nodes providing the information so you can quickly modify them when necessary.
Yes! Unpacking the structures in node editors is EXACTLY what we need. Not just for GN, but also BSDFs in Shader Editor. That would allow for massive additions in terms of flexibility and efficiency.
The only thing I disagree with is naming. We already have a naming for this in Blender: Combine and Separate, for example Combine XYZ and Separate XYZ, so these should be called Combine Geometry and Separate Geometry.
That would be a misnomer, because what I propose is a bundler for any noodle. Not just geometry.
Maybe Bundler node is not the best. Maybe just ‘Combine’ and ‘Separate’ without further specifiers?
Will this portal link feature come to 3.2?
I made a little mockup how I liked this to behave. I thought using reroutes would make some sense
or just make the reroute dots expandable to a node with ‘h’, in noncompact display it could have a setting to select the receiving node and an option to show/hide the noodle or change its hue and opacity
edit: like this
I really like this idea. Expanding reroutes to become portals when hit with a hotkey we’re already all familiar with… that needs visual design but I think this is spot-on
Having some sort of “jump to source/destination” operation - for all sockets rather than just reroutes - would be really generally useful!
I personally would like “portals” to just be hidden node links; preferably activated with a similar swipe gesture to cutting/muting and displayed similar to Erindale’s mock up. I think that could make cleaning up node trees a breeze.
Maybe with some kind of debug overlay to show links despite being hidden.
I also prototyped auto-propagating reroute labels from connected sockets/reroutes and together with hidden links (or D13675) I could see this being handy:
If we get node instancing functionality, we can instance a reroute node and get the same result as portals.
I am so excited for this functionality!
It would make nodes so much more organized 
I’ve been thinking about this, and the main issue I worry about is that when people start using this to make node networks, hidden links will inevitably create some confusion. The idea of node based workflows is that the connections actually show you how the data flows. If you give users option to hide these connections, node networks turn into clouds of randomly floating disconnected node rectangles, especially if people overuse it.
I think it can be useful, but most of the proposals for the portal design above fluctuate between two extremes:
I think rather than having to choose between the two extremes, we should have something in between. Something that’s more obvious than a simple named reroute circle, but something that’s not as visually and mechanically complex as a full node.
Here’s my idea:
Mechanically, there are some unanswered questions still:
What would happen if you have multiple portal inputs and one portal output of same name? This implies that simple portals should be always limited to a single instance of input of a given name.
We may need additional type of portal - a multi-socket portal, similar to the socke type for example the join geometry node has. This portal type would allow multiple instances of input of a given name, so that you could use multiple portal inputs in your node tree, and just single output feeding into for example the join geometry node.
That way, you would not need to have a large vertical column of multiple, individually named portal outputs next to your join geometry node.
On the other hand, this could actually be a good thing. Having multiple portal outputs labeled for example “Roof”, “Walls”, “Floors”, “Windows”, etc… feeding into a join geometry node is more communicative than just having one “My Geometry stuff” portal output feeding into it. So when you want to collect geometry outputs from multiple places across your node network to join them together at some terminal point, to prevent node graphs like these:
