A problem of the node preview addon is that it isn’t macOS-compatible, so, just from that standpoint a native solution would be great.
As for an in-node viewer vs. a viewer node, the in-node version could be in a collapsed state by default, so, not taxing the system from the moment one opens the Shader Editor. Ideally, it ought to save its state in the .blend file so that one doesn’t have to re-expand them every time.
I just let you know that I applied for GSOC with this project, and I plan to make node previews as it was previously before Cycles.
See you later if I get accepted 
Node Previews add-on has a functionality where you can disable it by default and only toggle it for certain nodes. For me, functionality can’t be any better than that. I can choose where I want and how many I want. As others told you before, original UX idea you proposed is flawed, but I agree that if there is a performance gain it is worth doing.
UI-wise Node Previews add-on is perfect for me, previews on top of nodes (opposed to inside the nodes, as it was before) is much better looking if you ask me. add-on also gives you ability to set preview sizes in the preferences.
Basically if I were you I would just copy that add-on, but make it in C++ and much faster. I don’t see any downside to add-on besides performance
I do think there is merit to a preview node, because you can preview your work exactly where you want it. Eventually, you can remove the excess nodes you no longer need to clean up the shader and save on performance. I mean, you might be able to activate a preview node by modifier + mouse click or hovering the mouse over a noodle and hitting a shortcut. That is as convenient as it gets.
Of course, a double click expansion of a shader node to show a preview. But, it’s much harder to backtrack where you have these and which ones you want to keep or want to remove. Although they can certainly be helpful for nodes with lots of inputs (like the principled BSDF), they change the actual node tree arrangement (you need to make space for the preview dropdown, whereas the preview nodes only affect the horizontal space of the tree, so you could in theory, expand the node tree to fit a preview node and shrink it back when you delete one.
You could preview your node exactly where you want it without the preview node. I don’t see why you wouldn’t?.. And there’s no need to clean up anything if there’s no such thing as a preview node. You just turn off the “Preview eye icon” on nodes that you don’t want to see a preview on…
Alternatively, the preview could just be in the N shelf, Node tab.
No need for any eye icons or anything like that… And no cleanup, as you would only see one at a time.
Yes, that is what I plan to do.
The original post I made was about an idea of mine, but it turned out that is was not relevant to the needs. As many mentioned here, the old system was nice, and I’ll mainly try to have it back on. Maybe considering to have a preview in the N shelf could be interesting, I’ll see later.
Edit:
I’ve been accepted to GSoC 
I think students usually create dedicated threads for weekly reports and feedbacks. This thread will be used for feedback.
This will be very convenient to have! I’d be interested to see some work on a visual mockup before coding work starts though, so that can be agreed upon. On that topic, I’d like to see the previews use something like the node overlays concept. So rather than going inside the node, changing its size, they would look more like a temporary popover that can be toggled, sitting above the node, rendered on top of everything else. Geometry nodes does this already, though only with text right now:
That would help to separate the shader instructions (the stuff inside the node) from the previews and results conceptually, and would make it easier to arrange nodes, since they wouldn’t change size and overlap each other when toggling previews.
Well, it makes a lot of sens to use this kind of popover for nodes.
Like other people here said, the location of the preview is to be thought carefully, but in any way, changing the location is not that hard when the preview will be working. It is nevertheless not to be forgot, I’ll make a little mockup in the following days for users to think about this perspective.
Thank you for pointing out this option that is really interesting.
Compositing and texture nodes already show previews. I’m not opposed to changing the UI, but if we do it should be consistent across node systems I think.
For this GSoC project, I’d consider making changes to this UI a stretch goal, after all the other parts work.
I don’t think previews work for texture nodes. Using overlays would be inconsistent with compositing nodes, but consistent with geometry nodes.
I’m not sure how much any existing implementation would be reused for this though. I’d hope that the compositor implementation wouldn’t be used anyway-- the “node instance hash” system used for it doesn’t fit well with more recent node developments. Previews should be stored in a data structure that’s completely separate from bNodeTree and looked up at draw-time.
I think that having the preview above or under the node would be better, since currently the part with the links gets shifted downwards, which moves the wires around when the preview is toggled.
On the topic of that, unlike the compositing nodes, many shader nodes have multiple outputs, so a design of selecting which output to preview, and showing which output is currently being displayed will have to be made.
I’d like to quickly add, a nice feature to have could be toggling the color channels to be displayed in the preview of color/vector outputs.
Seems like an MVP for what it would look like - make an overlay for the image input nodes?
It’s definitely not needed to preview every single node…
A similar approach to geometry node would be nice, a preview dedicated output
or passthrough like this
Are smart designs that do not interfere with the node styles.
Best to ask for user’s opinions on social media to reach the masses before taking design decisions like these 
Came here to say this. Not only noodles getting shift buts its very annoying when you turn it on and your sliders suddenly pop down and you have to scroll. Geometry Nodes has perfect concept for it and i would like to see this concept use that, newer UI design rather than older, Compositor one. And then update Compositor to this method
Hey ! I make a little sketch from your base. For me he do more looking like that i hope you like it !
“It’s definitely not needed to preview every single node…”
Sure it is, anyone who needs complete control over the node flow will need it, look at Substance designer, imagine making textures without previews on every node, you would lose sanity real quick.
However, that does not mean that it shouldn’t be flexible, it should cater to multiple workflows:
Preview window on all nodes,
Preview node on the graph if you have node preview turned off,
etc.
And it would make sense that the preview window is outside the node as if it were inside it would mess up the node flow of inputs and outputs.
Unless you make a visual design change about how node windows behave, it shouldn’t just be tucked on.
That addon on BlendMarket is the perfect example what’s efficient without disrupting the flow of the node itself.
Then all blender node magicians must be insane already 
Note that a dedicated preview node could give us the possibility later to add preview settings.
Implementing preview settings on generic “for-every-nodes” designs would be more tedious , perhaps.
What do i mean by preview settings? For example the user would want to preview on a 3d sphere? or on a suzanne? or on a 2d plane? Exactly like currenty preview system in the material properties
Why the padding and square ratio tho? 
Here’s a mockup with no padding, ratio would be adaptive to the node width, and the preview icon is similar to the old geometry node preview icon
Basicly a texture is in square format… You can’t make your node like that… and the advantage to the square already present in the node when he spawning is the place are already definied and you don’t need again to move your node. And you can choose if you want activate or disabled the preview by clicking in the X icon is very simple.
See all texture preview, everything are in square ! Is a preview of texture not a render by camera remember that.
See below a few exemple of node preview :
Octane :
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
3ds max
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
maya
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
Unity
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
unreal
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
Substance designer
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO…
In conclusion, the format need and applied are square. Texture are systematcly in Square format (64x64 - 128x128 - 256x256 - 512x512 -1024x1024 - 2048x2048 - 4096x4096 - 8192x8192 etc etc…)
I wouldn’t have the preview be part of the existing node layout. I don’t think having either the node’s title bar OR the contents shift vertically whenever the preview is toggled is acceptable from a UX perspective, when there are solutions that avoid this issue entirely. Obviously the preview could be placed above, it’s not quite a convention yet but geometry nodes do this with statistics already so that would be consistent. reducing vertical occupancy on mostly horizontal displays makes sense to me.
What do you think ?
Create a unity style node ? is the best deal the user need the both side connection…
Vertically :
Horizontaly :
SEE GOOGLE MY IMAGE WAS DELETED BY A MODO… (Unity shader nodes preview)
But horizontally are not ok with the default pipeline of blender… you see the reuslt final are Verticaly.
