@Gijs Much appreciated!
Perhaps if you had a better understanding of the underlying mathematics it would help you understand the complexity of the task, and the appropriate workflow to achieve your desired results. According to Sederberg (2017) Computer Aided Geometric Design Course Notes pages 34-35, a circle is approximated by a degree 5 rational Bezier curve (NURBS curve). Circular arcs can be approximated by degree 2 curves up to and approaching 180°, and degree three rational Bezier curves approaching 240° of arc. However, to approximate a circle using a NURBS curve requires a degree 5 rational Bezier curve. Once a circular NURBS curve is established, it is almost trivial to cut it into parts of any desired arc-angle – the subdivision algorithm is quite simple and yields robust, exact results. So, your ultimate outcome from a properly coded algorithm would be a degree 5 curve that is a subdivision of an approximation of a circle. Likewise for surfaces; the defining curves being generated by circular sweeps of the control points. A good algorithm would be to generate a 360° sweep and then split it by isocurve at the desired angle; encapsulate such an operation within a command and it should be amenable to replication by the the History function. (Rhino appears to natively use even higher-degree approximations of the circle.)
My understanding is Rhino uses the circle representation described in “The NURBS Book 2nd edition” Sec 7.5 Ex7.3 pp 299-300; a closed rational degree 2 NURBS curve with 4 spans and fully multiple knots (Not a single span Bezeir curve). This representation of a circle is exact. Arcs less than a full circle use similar representations.
Perhaps is should be noted that these representations are G2 continuous everywhere including at the multi-knots. They do not have “kinks” in the usual definition of “kink” as a point where the continuity is G0 only.
Your post above and your reference are about rational Bezier (single span) representations while my understanding is @Lagom is requesting a non-rational degree 5 multi-span representation in the revolved direction.
Rational representations of circles, arcs and revolved surfaces have the advantage of being exact but can have significant disadvantages when used in surface modeling. With a suitable choice of degree, number of control points and control point location the deviation of a non-rational representation can be kept within an acceptable amount. For example the deviation from an exact circle of a non-rational degee 5 with 8 control points curve is 0.002 percent of the radius.
The Revolve command default uses an exact rational representation in the revolved direction. It has the deformable option which uses a non-rational representation with a user specified degree and number of points. Lagom in the first post in this thread points out a problem with that option when used with degree 5 and less than 360 degree revolution. Gijs submitted a YT request to fix that problem.
The desired result is a Revolve tool that works like one expects it: A non-wobbly partial surface of revolution of degree 3, or degree 5 as a bonus : )
I stand corrected. The default Circle command (deformable option, degree 5 option) produces a non-rational degree 5 periodic NURBS curve having 12 control points (internally), 5 of which are duplicates yielding the appearance of only 7 control points to represent the circle. Also, my suggestion for how one might generate the revolve that @Lagom seeks by first generating a “360° sweep” was hastily written; I meant Rail Revolve, not Sweep.
An algorithm that works is to create a deformable, degree 5 Circle (and its axis for the subsequent Revolve), then Trim the circle to the desired angular extent. Make a Rail Revolve along the resulting arc. The result is a degree 5 non-rational surface in the circumferential direction. I believe this meets the original intent:
Perhaps this sequence of operations could be packaged into a single command that would respect History (not break History).
I think I understand what @Lagom means when he says that resulting surfaces of some of the various algorithms discussed in this thread are “unusable.” I do some surfacing work that requires obtaining optical properties (“class-A surfaces”) which, in turn, requires control of the curvature and the rate-of-change of curvature (“flow”) across the whole surface, even to the edges in some cases. The degree 5 non-rational curve in the circumferential direction yields a revolved surface that maintains almost-exact, constant curvature all the way to the edges of the surface, yielding an untrimmed edge to which one can later Match. This is preferable to the degree 3 or the degree 2 rational approximations for surfacing work and becomes mandatory for optical work.
Thanks for bringing this to my attention, @Lagom
This proceedure was proposed and discussed above. Unfortunately Lagom made fundamental error when he tried it (see post 18 above for the details) and erroneously concluded the result was unusable.
What do you mean by “degree 2 rational approximations”? There is an exact degree 2 rational form for the revolve direction of a surface which Rhino uses. Where is an approximation used?
The result of Revolve for less than 360° was and is unusable, see initial post.
Considering machine precision, it is an approximation, is it not?
The algebraic equation for a degree 2 rational revolvee surface is exact. Rhino uses double precison floating point math, which means the accurcy of a 100 mm radius revolved surface will be better than 0.00000000001 mm or 0.00001 nanometer or 1/1,000,000,000,000 of the wavelength of visible light. I consider that to be essentially exact for any purpose.
In contrast the algebraic equation of is approximate. Using 8 control points it’s deviation is around
200,000 times larger than that of the exact degree 2 rational surface. A 100 mm radius revolved surface will have an accuracy of apprroximately 0.002 mm or 2000 nanometers, or a bit larger than the wavelength of visible light.
FYI: For next Rhino 8 service release, @mikko has fixed the curvature issue and in Rhino 9 he has added an additional option to change the degree in radial direction (1-11).
I’ve been thoroughly skewered. 
You mean, curvature regarding the degree 3 sub-360° revolve? That’s a good step forward!
Yes
I mentioned this since the fix is partly in Rhino 8 and partly in Rhino 9. The additional wish for setting the degree goes into Rhino 9
Despite the inaccuracy of my words (pun intended!), I believe that the result of a Rail Revolve using an arc segment taken from a degree 5 deformable Circle or using a degree 5 deformable Arc meets the request and can be used as a workaround until the release of Rhino 9 (or the next service release?).
Another comment on “exact” and “approximate” representations of revolved surfaces:
There are many situations where use of a degree 3 or degree 5 non-rational approximate representation of a revolved surface is preferable to use of an exact rational representation; for example if the revolved surface will be later manipulated. The user does need to confirm that the approximate representation uses a sufficient number of control points to provide the level of accuracy needed.
I completely agree. See my post 11 above:
As I mentioned previously @Lagom unfortunately clicked on the wrong location for the revolve axis when he tried the method using my example, Consequently his result was badly distorted. That result led him to conclude that the RailRevolve method was “unusable”. See post 19 for more information.
Well, it’s a crutch. One has to draw that extra circle segment.
Aye. And retain it if using History is anticipated.
I think you and @davidcockey have caused me to learn a great deal because of this issue, and it looks like @Gijs and @mikko are on the task of revising the Revolve command. I think your issue will shortly be resolved.
My hat is off to those three, and the whole McNeel team; McNeel has the absolute best user support of any software I’ve ever used. Where else can one learn the inner workings of their software tools and get interactive product support late on a Saturday?
Preferred beverages to all! 
