Generally, we prefer UI consistency and a simpler UI ruleset over preventing users from doing silly things.

An example is that you can "Send Message" to yourself from your profile. This option isn't very useful, but it's consistent and makes the interface more predictable.

Some of the problems with trying to prevent users from doing silly things include:

• When we remove options without explanation, this is potentially much more confusing if a user expects the option to exist but it does not, and there's no hint or explanation as to why. The rule ("You can't set a project's policy to itself", "you can't message yourself") may be intuitive to us in context, but often isn't intuitive to a new user out of context. Giving users UIs that are confusing and offer no path forward is bad for them and increases our support burden, so this approach is generally off the table.
• So the minimum level of UI affordance is normally to either disable options with an explanation, or warn users about selecting "silly" options. For example, in this case, we might grey out the project name (but still show it as an option) and pop up a dialog when you try to select it. This fixes the "total confusion / no path forward" scenario that users can encounter if we simply remove the option, by letting them select the option and then learn the rule which disables it. However, this is often a lot of complexity for a very questionable benefit. In this case, it's not clear to me that preventing users from selecting this policy and telling them to select a different, equivalent policy would actually make the interface better: it seems like a lot of work for us and for the user to achieve the same result.
• We may not be able to guess which things are "merely silly" vs "silly and completely useless". For example, using "Send Message" on yourself can be useful for testing/development. Users might use it to write notes to themselves. Users might think this way of expressing "joinable by" is more clear. In all of these cases, the utility is probably very marginal, but it's hard to be sure that there's zero utility in an option. Since we're often talking about removing options which work correctly, are consistent, and obey all the UI rules, it's not like we're removing broken options: they work fine, and in some cases users do use them for something. So we can harm real use cases by mandating that certain options are too silly to exist.

Of course, there's a balance here. For example, if users are frequently having trouble accurately expressing intent in a UI, that suggests we should change things, and removing "silly" options might be one approach. However, that's the root issue we'd want to tackle, and this report doesn't suggest that the UI is actually confusing, just that it doesn't force policies to be specified in minimal form. We don't require this, and can't realistically require this: there are infinite policies that evaluate to "no one", and some are almost certainly more intuitive in some contexts than "No One" is.

When the root of a problem is "it is possible to do something silly", but that silly thing is consistent, works in an intuitive way, allowing it gives us a simpler ruleset, and the silly thing doesn't cause harm on its own, we'll almost always allow the silly thing. Disallowing the silly thing makes the code more complex, makes the UI more complex, often does little practical good, and may harm off-label use cases.

Finally, here's a goofy scenario where this setting might be useful and desirable:

• You have a project called "People who can Join Projects".
• You set the default join policy for new projects to "Members of People who can Join Projects".
• If you set the project join policy to itself, the policy hint will show grey ("standard policy") in the header.
• If you set the project join policy to "No One", the policy hint will show red ("more restrictive policy") in the header, which has the same effect but is arguably less intuitive because it's actually the standard policy.