thanks @Gijs
I know of a hack in rhino that allows you to complete the continuity of g2 g3 and g4 without the points being derailed or destroyed. it gives much better results compared to what matchesrf and blendsrf offer here.
if really there is a development work to improve these two tools. I post what I think are workarounds or less for 50% more efficiency. but I don’t know if it translates easily or not or if it can be integrated as a background solution.
I wouldn’t say that the VSR surface matching is perfect - but it’s VERY close. You can even do cool stuff like follow the surface direction on one edge, and maintain the surface direction on the other edge. I show some examples in that thread how VSR works properly. Every once in a while it will do something wrong, and then you just use Surface Matching Analysis tool with Control Point Modeling to manually match. Once you understand the theory (and have the right tools) manual matching is actually an extremely efficient way of getting the absolute best quality from your matches.
Here’s a great example of (one of) these issues:
VSR does this match PERFECTLY, Rhino produces an undesirable/not useful result.
I think that Sky and Bobi should be hired by McNeel to consult polishing modeling tools. I would love to see how would look Rhino then and I would love to work with that tool then. I’m saying it on blind after their many analysis of how that tools should work correctly. As I said before I`m happy that Gijs is on board which can mean that McNeel wants to bend more into the puristic modelling side where Rhino roots really are. I keep my finger crossed.
Along with @Gijs , I should mention @pascal as two great examples of helping persons who have made so many truly useful scripts, that, for some reason, remain unused in Rhino. I would love to see many of these scripts being included as native tools in Rhino.
No kidding, the developers at “McNeel” should start a full-time 3d modeling job with Rhino every second day of the week, in order to truly understand the need for better surfacing tools, static Zebra and Light lines analysis, mass calculation, usable rebuild to single-span surfaces (6 control points and degree 5), Gumball with integrated extra handles for “Drag strength”, etc. Only then they will figure out that the current tools in Rhino are underdeveloped and lack major functionalities that could make the workflow much simpler and easier.
Even MOI has a vertical dimension in the Perspective viewport, but Rhino don’t. Hint:
! _CPlane _Object _Multipause _DimAligned _CPlane _Undo
or
! _CPlane _Object _Multipause _Dim _CPlane _Undo
With the a addition of a few minor items like you mentioned above, I really think that Rhino could get broader adoption in automotive as well. I’m one of only a small group of people that use Rhino it at my work and we use it more and more for a variety of case specific applications. Alias seems to be getting worse and worse every year and any advantage its had is minimal at best. There is definitely an opportunity for McNeel to scoop up market share in this area.
When it comes to control point editing, there are a few weaknesses of Rhino:
Missing arrow handles directly on the control polygon, in a similar fashion like the ones in Alias and ICEM. Control point manipulation is a real pain in Rhino, because the Drag modes are not convenient to use. “MoveUVN” is nice, but not enough;
“MoveUVN” lacks:
a) Its own Undo button inside the pop-up panel;
b) Snappy sliders, which is essential in cases where the user wants to move the former at equal distances to left or right;
c) Ability to cancel the movement of the slider by right-clicking while still dragging it with the left mouse button (other Rhino commands already take advantage of this feature);
The Gumball must have additional handles for Drag strength (see post #96 in the link below).
Inability to switch between “Snappy dragging” and “Smooth dragging” by tapping the Tab key while dragging some of its handles (see post #99 in the same topic linked above).
Missing “U” and “V” labels next to the edges of the edited surface. May also include some arrow to mark the direction of the edges all the time, instead of the need to run a separate command for this.
whats VSR
Ahh I vaguely memba 
that …
“Virtual Shape Research GmbH (VSR), a developer of a class-A surface 3D modeling plug-in for Rhino.”
I will mention it for the millionth time: “Explicit control” must be added to the major surfacing tools of Rhino. To make it work properly, however, Rhino first needs to be capable of converting to single-span surfaces in an optimized way, unlike the current situation where it tends to create hugely distorted zig-zag control polygon after rebuilding to degree 5.
I think McNeel doesn’t want to compete too much with Autodesk or Dassault (which in fact absorbed Icem).
It’s obviously my guess but I’ve been trying to solve these modeling problems for years and I’ve found a workflow that comes close to the results of Alias/Icem but requires too many loops and remains too rigid and restrictive.
3 years ago I also tried building a tool with Grasshopper but it wasn’t able to move the existing CVs and so I abandoned the attempt (and I don’t know if it’s able to do it today).
Fortunately, in the large company where I work, I can delegate the modeling activity via Alias/Icem to someone else and therefore devote myself more to setting up and feasibility, but I’d like to be more autonomous in generating proposals that someone else will then bring to A-Class.
But it is clear that I am an exception and in my opinion McNeel does not intentionally improve these tools and has indeed decided to concentrate its resources on features that have greater customer appeal such as subdivision surfaces which in the automotive world can only be used in very specific and restricted situations and certainly not in the feasibility phases when I have to introduce all the information of draft-angle, mold direction, parting line management, assembly features, etc… in the world of feasibility subd-surfs are absolutely a useless toy.
But the appeal of subd-surf for less demanding users is perhaps very great and this unfortunately distracts McNeel from the more professional tools.
My understanding is that McNeel, in some way, is interested in improving that kind of tools, otherwise they would not have open this thread and asking for suggestions.
I hope I am right.
I hope you are right 
But the post i quite old and no news on the SR.
So many people were giving feedback and suggestions over the past 10-15 years, now it’s time to see if the developers will truly focus on improving the main tools for NURBS surfacing. I just checked what’s new in Rhino 8 WIP and I can’t find a single NURBS surface creation tool that’s better than its counterpart in Rhino 7.
Rhino 7 focused primarily on more mesh tools and SubD, Rhino 8 WIP is focused on more mesh tools and SubD. In fact, the only thing I like in Rhino 8 WIP is the auto-hiding Properties panel…
Could someone show me any major improvement or a new tool for NURBS surfacing in Rhino 8 WIP that are included in the list below? I only see " FitCurvetoSurface" and it has limited usage compared to “Blend surface”, “Match surface”, “Sweep 1 rail”, “Sweep 2 rails”, “Loft”, “Network surface”, “Patch” (“Xnurbs” is a great example of a proper patch tool) that largely remain the same as in Rhino 6. there are still no arrow handles on the control polygon for direct control point manipulation. Gumball with “Drag strength” handles is also something that I doubt I will see in Rhino soon enough before I retire.
For surfacing related commands, I think this is the current list of changes.
FilletSrf has now a dialog box version (old style is using dashed version -FilletSrf) with more options:
FilletSrfToRail (new)
FilletSrfCrv (new)
RefitTrim has been improved
SplitRefitSurface (new)
BlendSrf will now remember its handle slider settings when editing
FitCurveToSurface (new)
ConvertToSingleSpans (new)
Forgive me but it is absolutely not enough and is far from a coordinated system for the creation of surfaces comparable to Icem and Alias!
And I insist on the concept of system since all the surfacing and curve editing tools must fit perfectly together.
Moreover the distribution of the CVs and the optimization of the complexity of the surfaces must be improved as well as Icem manages to do!
Then as Alias/Icem you have to add all the possible methods of checking the alignments and distribution of the CVs.
Thank for sharing that list! From what I have tested so far, seems like only the lesser deviations of “Refit trim” and the deformable G1 and G2 blend of “Fillet surface” are usable for NURBS surfacing. The rest are minor in comparison with the lacking features of “Blend surface” and “Match surface” that were requested so many times… Not to mention the lack of “Explicit control”, which is one of the most important options in Alias and what gives it so much power for quality and lightweight surfacing.
Rhino 8 WIP crashed several times while trying to use “SplitRefitSurface”. Just a few seconds ago it crashed again at the moment I clicked on its icon. Not funny.
RhinoDotNetCrash.txt (4.7 KB)
I also experienced lost of weird issues with the UI, especially with random giving focus to programs in the background (while trying to open or drag floating panels) and mouse tooltips that go far away from their corresponding icons.
Yes I agree on several of these points. One of my workarounds for CV manipulation in Rhino (specifically along the control polygon) is to bind an alias (in this case I’m using a Stream Deck) to:
Command: '_PopupToolbar
Name of toolbar to open: “default.Drag Mode”
The catch is, that you have to toggle the gumball OFF for this to work. having a gumball like widget on the cv would be nice, but my selection radius is usually works fine.
Its also interesting you mentioned the UV direction indication. I’m working on a loose loft tool that allows you to change degree and add crown when creating the surface that functions a lot like the skin tool in Alias and this is something that I’m incorporating in to the display options
