Environment patterns should be folder-aware
Description
We use environment patterns in a few places; cluster, secret variables, maybe elsewhere. But we also encourage a convention of folders to organize environments. e.g. review/branch-1. We can use a pattern like review/* to refer to these foldered environments, but what about mixed usage like production and production/emea? Or for that matter, providing defaults that will catch either of those cases even if one user doesn't mix them, different users may use a top-level production environment whereas others may use nested production environments because they have more than one. Because we're using patterns and not regex, the pattern that would match would be production*, which may be a little too permissive. With a regex, you could do production[/.*], but while technically correct, is also kind of ugly. In particular, we're considering displaying these environment patterns as part of the identity of the underlying item. e.g. If a cluster is for production*, we'd call it the production* cluster, which isn't pretty. What I want, is to call it the production cluster, but without having to create a separate name just to overcome the ugly pattern.
Proposal
What if we handled folders a bit differently and only matched the pattern on the part before the /? That way production would automatically match production and production/emea. review would match review/branch-1. This makes it easier for people to configure these items, and makes them more easily referencable. We can talk about the production cluster, for example.
Another options is to only do this if there is no / in the pattern. If there is, then treat it more explicitly. e.g. review/* would match review/branch-1, but would not match review. Likewise, a production/emea variable or cluster would only apply to that specific environment.
I have a hunch this will be more intuitive for people, but there is possibility of it being more confusing as it's not behaving like a regex nor a straight pattern match. We could maybe clarify that by saying we're matching pattern on the top-level name only, unless an explicit / is present.