While dual-handle usage (min/max price filters) is the most common use case, the foundation of the API supports adding more than two handles.

Community feedback provides specific, validated use cases where 3 or more handles are necessary, which confirms the design choice to support N handles, the use cases are however, limited.

A few Justifications for 3+ Handles:

• 4 Handles: Opening Hours Selector to manage separate open and close times (e.g., AM shift and PM shift), which is demonstrated in the prototype and mentioned by developers.
• 3+ Handles: Data visualization tasks, such as setting bin sizes across a histogram, or complex category allocation in budget tracking.
• N Handles: Used in Color gradient selectors.

There is, however, a caveat here. Most people I talk to tell me that they haven't used more than two handles, mostly because a library didn't support it, and then another way was easier (this also resulted in the form, a lot of examples with two thumbs, barely any with more).

However, many are excited that if it were possible, there might be new ways to visualize ranges.

So, I'd love to ask confirmation here. Based on the (currently) limited use cases. Do we want to continue with this idea for an API.
I feel that this API opens up possibilities that weren't there yet and can be made accessible in a clean way.

The other way would be a lot of attribute additions, which I feel could get bloated really fast.

The community is positive of the idea to have N-thumbs, but once again use cases are limited.

My main question here is: Is there actually a case against the capability of making it more than 2 thumbs based on the current API design?
Should there be a limit (also from an engineering standpoint)? Or is the author's responsibility?