From the conda docs on managing virtual packages:

Managing virtual packages

"Virtual" packages are injected into the conda solver to allow real packages to depend on features present on the system that cannot be managed directly by conda, like system driver versions or CPU features. Virtual packages are not real packages and not displayed by conda list. Instead conda runs a small bit of code to detect the presence or absence of the system feature that corresponds to the package. The currently supported list of virtual packages includes:

• __cuda: Maximum version of CUDA supported by the display driver.
• __osx: OSX version if applicable.
• __glibc: Version of glibc supported by the OS.

Hence, feature refers to a system feature, in this case the supported version of the display driver.

Per the conda package specification, __cuda==11.1 means that the display driver must exactly match one of the cuda versions 11.1, 11.1.0, 11.1.0.0, and so on.

The MatchSpec query language for conda packages

The conda source code file match_spec.py defines the MatchSpec class. The docstring for this class includes the technical specification for conda packages.

`MatchSpec` is, fundamentally, a query language for conda packages.  Any
of the fields that comprise a `PackageRecord` can be used to compose a 
`MatchSpec`.
 
`MatchSpec` can be composed with keyword arguments, where keys are any of 
the attributes of `PackageRecord`.  Values for keyword arguments are the 
exact values the attribute should match against.  Many fields can also be 
matched against non-exact values--by including wildcard `*` and `>`/`<` 
ranges--where supported.  Any non-specified field is the equivalent of a 
full wildcard match. 

`MatchSpec` can also be composed using a single positional argument, with 
optional keyword arguments.  Keyword arguments also override any 
conflicting information provided in the positional argument.  The 
positional argument can be either an existing `MatchSpec` instance or a 
string.  Conda has historically had several string representations for 
equivalent `MatchSpec`s.  This `MatchSpec` should accept any existing 
valid spec string, and correctly compose a `MatchSpec` instance.
    
A series of rules are now followed for creating the canonical string 
representation of a `MatchSpec` instance. The canonical string 
representation can generically be represented by 

    (channel(/subdir):(namespace):)name(version(build))[key1=value1,key2=value2]

where `()` indicate optional fields.  The rules for constructing a 
canonical string representation are:

    1. `name` (i.e. "package name") is required, but its value can be '*'.  
       Its position is always outside the key-value brackets.
    2. If `version` is an exact version, it goes outside the key-value 
       brackets and is prepended by `==`. If `version` is a "fuzzy" value 
       (e.g. `1.11.*`), it goes outside the key-value brackets with the 
       `.*` left off and is prepended by `=`.  Otherwise `version` is 
       included inside key-value brackets.
    3. If `version` is an exact version, and `build` is an exact value, 
       `build` goes outside key-value brackets prepended by a `=`.  
       Otherwise, `build` goes inside key-value brackets. `build_string` 
       is an alias for `build`.
    4. The `namespace` position is being held for a future conda feature.
    5. If `channel` is included and is an exact value, a `::` separator is 
       used between `channel` and `name`.  `channel` can either be a 
       canonical channel name or a channel url.  In the canonical string 
       representation, the canonical channel name will always be used.
    6. If `channel` is an exact value and `subdir` is an exact value, 
       `subdir` is appended to `channel` with a `/` separator.  Otherwise, 
       `subdir` is included in the key-value brackets.
    7. Key-value brackets can be delimited by comma, space, or 
       comma+space.  Value can optionally be wrapped in single or double 
       quotes, but must be wrapped if `value` contains a comma, space, or 
       equal sign.  The canonical format uses comma delimiters and single 
       quotes.
    8. When constructing a `MatchSpec` instance from a string, any 
       key-value pair given inside the key-value brackets overrides any 
       matching parameter given outside the brackets. 

When `MatchSpec` attribute values are simple strings, the are interpreted 
using the following conventions:
  - If the string begins with `^` and ends with `$`, it is converted 
    to a regex.
  - If the string contains an asterisk (`*`), it is transformed from a 
    glob to a regex.
  - Otherwise, an exact match to the string is sought.


Examples:
    >>> str(MatchSpec(name='foo', build='py2*', channel='conda-forge'))
    'conda-forge::foo[build=py2*]'
    >>> str(MatchSpec('foo 1.0 py27_0'))
    'foo==1.0=py27_0'
    >>> str(MatchSpec('foo=1.0=py27_0'))
    'foo==1.0=py27_0'
    >>> str(MatchSpec('conda-forge::foo[version=1.0.*]'))
    'conda-forge::foo=1.0'
    >>> str(MatchSpec('conda-forge/linux-64::foo>=1.0'))
    "conda-forge/linux-64::foo[version='>=1.0']"
    >>> str(MatchSpec('*/linux-64::foo>=1.0'))
    "foo[subdir=linux-64,version='>=1.0']"

To fully-specify a package with a full, exact spec, the fields
  - channel
  - subdir
  - name
  - version
  - build
must be given as exact values.  In the future, the namespace field will be 
added to this list.

Alternatively, an exact spec is given by 
'*[md5=12345678901234567890123456789012]'.

Going back to the original example:

feature:/win-64::__cuda==11.1=0

According to the MatchSpec definitions above:

• feature - The virtual package channel.
• :/win-64 - The virtual package channel subdirectory, indicating the system is a 64-bit version of the Windows operating system.
• :: - Since the channel field is included and is an exact value, a :: separator is used between channel and name.
• __cuda - The virtual package name, in this case referring to the display driver specification.
• == - Exact version matching constraint.
• 11.1 - The exact version to match, which includes 11.1, 11.1.0, 11.1.0.0 etc.
• =0 - Since version is an exact version, and build is an exact value (in this case 0), then an = sign is prepended.