> A well defined domain model should indicate what that structure represents.

"Should", but does it? If a function returns Option<HashSet<UserId>> I know immediately that this function may or may not return the set, and if it does return the set, they are unique.

This is a fact of the program, I may not know "why" or "when" it does what. But as a caller, I can guarantee that I handled every possible code path. I wouldn't get surprised later one because, apparently, this thing can throw an exception, so my lock didn't get released.

it seems like you're just not familiar with the domains defined by those types, or at least the names used here

Are you? What would an option for a hash set of userids? I just don't find that "types" magically solve problems of cognitive load.

> What would an option for a hash set of userids?

As an argument: An optional filter for a query e.g. "return me posts form these users"

As a return value: The users who liked a post or nothing if it's not semantically valid for the post to be liked for some reason.

> I just don't find that "types" magically solve problems of cognitive load.

Cognitive load is about working memory and having to keep things in it. Without types one only has a name, say "userIds". The fact that it's possible for it to be null and that it's supposed to contain unique values has to be kept in working memory(an increase in cognitive load)

Even that means a lot more than `{}`, who's tortured journeys I have to painstakingly take notes om in the source code while I wonder what the heck happened to produce the stack trace...

Yes, but it means less than something like UserGroup. I hear you on {} though, I'm currently looking at "e: ".