Again, this is an unsupported feature and there's nothing in the docs that would suggest this would work. If you're using a ruleset as data (as a map), then you can't use guards and expect to access it, since there's no lookup format for accessing that data.

Closing as not supported.

You can however use conditional logic in the value itself, as in:

@switch: demo;
#lookup {
  @not-found: if(@switch = demo, 1, 0);
}
.example {
  @media (min-width: 700px) {
    not-error: #lookup[@not-found];
  }
}

If you're using a ruleset as data (as a map), then you can't use guards and expect to access it

I thought I had understood (though not agreed). Then I stumbled upon this:

#desktop (@ruleset) {
  @media (min-width: 700px) {
    @ruleset();
  }
}

@switch: demo;

.example {
  #lookup () when (@switch = demo) {
    @not-found: 1;
  }

  #desktop({
    wut: #lookup[@not-found];
  });
}

Expected and actual output:

@media (min-width: 700px) {
  .example {
    wut: 1;
  }
}

The only difference being that the namespace is parametric and that I'm very confused now. I seem to have found a solution to my problem, but please explain why one is supported but the other is not.

@ahultgren Oh interesting.

Well unfortunately, you're in a narrow space where something may work, but also isn't supported so isn't guaranteed to work in the future. In other words, this is undefined behavior.

As to why it works, it probably has something to do with the fact that guards on regular selectors was added later, so it all depends where parsing is split. That is, simple selectors can be treated as mixins, but aren't internally captured as mixins. They have a different node type, so accessing them is also somewhat different. In fact, the ruleset structures of DRs, mixins, and selectors is internally so different (unfortunately), that the lookup logic had to be unique per structure. It's just because they were added at different times, and then sub-features like guards were also added later at different times to each.

Thanks for the explanation! I'm sure it makes sense to say that the behavior is undefined when looking at it from the perspective of the compiler. As an everyday user on the other hand, it seems weird that two features that each is supported can't be used together. It seems much more like all use cases weren't considered when adding one of the features (and is thus a bug) rather than explicitly not a supported use case.

Anyway this is not criticism, you're doing a great job and I'm not questioning this decision. I just wanted to share the perspective when you don't know the internals of less.

@ahultgren You're probably not wrong that the behaviors should at least align in some way, so I reopened this.