Sorry for all this long text, please take another coffee 
. The more I think about the idea, the more potential improvements I see. I hope you can see the impact it would have on workflows.
A component that creates ring bands, the metal part that surrounds the finger. It is like the pipe component, but it does not make arbitrary pipes, but one with known characteristics, such as having an inner side and an outer side and lateral sides. Let’s say that it is created with inputs: guide curve, section profiles, width, thickness, taps and a pair of scalars that define the distribution of the planes on the guide, but these last two are not editable by the user, they are internal parameters; and returns a brep with some particular characteristics (that other components will use). Basically the algorithm puts aligned planes in the guide curve, maps the sections from their original position to these planes, scales them, do loft and covers them. So, we are going to rethink how to define this hypothetical component, having another document for inputs and another for outputs.
That the curve is an object without orientation is a problem, because you have 360 degrees of freedom to align the planes in it, so you need to align them in some way that makes the sections fit. A good solution is to use the direction from the closest point on a aligner geometry to the position on the guide curve. But you need another parameter to include this aligner geometry, when in practice 90% of the time the same geometry is needed (a line on the Y axis to align cylindrically in ring bands that touch the finger). If not, you should restrict the use of the functionality of this tool including a default aligner geometry, but then you need other versions of this component to contemplate other scenarios. This is not very smart, so you end up putting another parameter so that the user can adjust it, although it is an argument that what is really defining is the input guide curve orientation by fixing the planes what do you get from this, but you have to include it as a tool argument. So with this idea, having a document for the inputs, you have everything, you can include a default geometry aligner that the user can change and you don’t need to include this optional parameter as component argument.
Section curves need a reference plane to perform orientation. They go from this plane to that plane on the guide curve. Similar to before, we can include another parameter to the component so that the user defines this reference plane associated with each section curve, or we can force the user to modify the curve so that it is in a specific orientation. If there were an editable default plane within the input document, for example the XY plane, the user could choose whether to adapt the curve or adapt the reference plane according to what interests them. Maybe you have several section profile styles and by how you build them, you can simply extract the plane of the curve. So in practice, as a developer you have to sacrifice the simplicity of using the component by adding an unnecessary parameter so as not to restrict the functionality. On the other hand, these curves must be flat and closed and the seams should be aligned, so you can throw an error if they are not, or force them to be flat with the reference plane and make it closed somehow (which the obvious solution does not always work), but this can be confusing for the user to modify the input without being aware. The solution again is to send these preprocessings to your own space to make it editable.
Width and thickness are scalar parameters that define the shape of a real object, therefore they have real measurements. Its value will be found within a sweet domain most of the time, or within a broader acceptable domain almost all the other times, and almost never in an extreme domain. However, the numeric parameter is infinite and no domain preference can be assigned, forcing either the developer or the user to define this routine everytime. Sometimes the developer cannot set limits because doesn’t want to restrict the functionality arbitrarily, but then the user must establish the domain in the slider every time. This could be solved with a preprocessing of these values so that, for example, they are in between of a minimum and maximum, but that the user can edit not only these min-max values, but also being able to use other logics, as appropriate to each case. Instead of use this input as a real value, it can be a normalized value an internaly in this input def. it is mapped to a sweet domain. On the other hand, these values instead of being a single value, could be a list, and this list may not be the same size as the number of planes/sections, which as a developer leads you to decide, how you synchronize the sizes of the lists? Do you repeat the last value until you fill it? do you interpolate or an envelope? you create another parameter to let the user select? The best thing would be to put a logic by default and that it can be changed, because depending on the context, you are more interested in one or the other, but you are not really interested in being able to change it at any time, but in changing it once.
Caps always present the same problem. One wants to put a parameter to choose the type (open, flat or rounded), but then, if it is the last case, you have to put a default height to not include an additional height parameter that only works if the type is rounded. If I had a definition of inputs, I could put there all the parameters that define this no trivial case (for arbitrary planar closed curves), to hide them from the component externally but to be able to change them when needed.
The other two inputs are two tolerances. There is no need to give these inputs to the user because the default value in most cases works well enough. But then an extreme case appears and because you cannot change that tolerances, your tool does not work or takes a whole life to compute. Accept that or fill the components with irrelevant parameters for most cases or add constrains in the code that sometimes will limit some regions of its functionality. However, having a definition for inputs, they could be left there as editable internal parameters.
Finally, you have other components that expect this type of ring bands to have internal, external and lateral surfaces, which follow a certain order in the brep. It is then the responsibility of the output to verify that this is true or fix it to ensure correct output. If there were a definition on outputs, you could remove this restriction if it doesn’t interest you at all for your particular context and you want to improve efficiency for example, or modify the logic in any way because is needed.
Returning to the idea in general. It has a lot of applicability, and reusability (the numbers are validated in 4 or 5 forms, the curves have their own forms, the surfaces may need to be closed…) so it could be empowered with snippets. When you leave the range of unconscious tools of the object that they modify (they know the geometry that is but not the object that it represents), development and modeling are full of heuristics. Those parts of the definitions that do not conceptually influence the algorithm but make it terribly spaghetti, could be hidden but accessible in another layer of abstraction, where argument processing takes place. When you make tools that model physical objects, you have to take many things for granted to gain simplicity for the user but losing versatility in functionality, or vice versa, give the user a lot of parameters that are only relevant in many situations, making difficult tools and tedious to use.
So a sensible way to solve all this would be to take the logic of the clusters on components towards the parameters. It makes more sense to me that the logic that modifies the parameter is contained in the parameter, which is the bridge between the user and the tool, where validation/restriction/any processing of arguments should occur… Instead of having expressions that parse text, it could be a definition with immutable parameters. The menu shortcut for graft, flatten, reverse… would be like snippets using those components. It seems to me that this has too many consequences so I leave it there for you to think about if it seems interesting to you, which I hope.
Excuse me again for the long text.
