I think it’s more confusing, because it’s ambiguous if it’s the list itself that’s unique or its elements.
But indeed, understanding why it’s called SET probably requires some computer science/math background. On the other hand, I can’t think of a more correct name. I think good docs can solve this schism, this isn’t user-facing functionality anyway. 
@rohhan :
I’m curious on your thoughts on why this needs to be singular. I can think of cases where this should be 1-n fields. In the same example, consider one review per productID and order.
Curious on this must-have. Could you elaborate on what you mean with “delete” here? I think it’s a bit surprising to be able to mutate the unique variable whatsoever for two reasons:
- Removing the value would mean you can indeed create a new instance, so the SET doesn’t apply historically, only at the tip. Hence, there is no way of knowing if there were indeed other instances.
- Changing the value means that a SET stream can be unique against different things at different points in history. I think this is very confusing.
Possibly this RFC resolves this. But I’m still curious to the reasons for these cases, because I’d assume I could still “see” there is a stream XYZ here, but the content has been deleted in the latest commit. Take deleted posts on this forum for example, it’s good for transparency that the “ref” is still there, even if the content is gone. I think it’s important that history can’t just disappear at the whim of the controller, which is what happens at the indexer level if a stream ref is removed or changed.