This is a spinoff of #8957. But I think this is small and separate
and a clear bug. I'm hoping this can be prioritized and fixed before
waiting for the full solution in #8957.

TBB has multiple-length version numbers: 2018, 2018.1, 2019, 2019.1,
etc. There are patches that apply to :2019.4, 2019.5:, etc.

I tried spack install intel-tbb @2019 and the concretizer picks rev
exactly 2019, not 2019.8. (This much is correct.) The problem (for
writing package.py files) is that 2019 satisfies both of these:

patch(..., when='@2019.6:')
patch(..., when='@:2019.2')

So, rev 2019 is both >= 2019.6 and <= 2019.2.

This makes it impossible to use version ranges for any package that
has variable-length versions. There is no valid order where this makes
sense. I'm guessing there are probably several packages with broken
version ranges that don't know it.

IMO, this is a clear bug, seperate from how you want to interpret
when='@2019' (the essence of #8957).

@adamjstewart diagnosed this in #8957 as:

I'm starting to get a better understanding of this most recent
bug. ver('2019') is a Version object and ver('2019.1:') is a
VersionRange object. In order to compare these two types of objects,
we coerce Version('2019') into VersionRange('2019:2019'). Thus,
2019.1: overlaps with 2019:2019.

So, maybe this problem can be fixed by redoing the comparisson: don't
test for overlap between two VersionRange objects. Instead, test if a
single Version is a member of a VersionRange.

Anyway, I think this is small and isolated and maybe can be fixed
without waiting for a full solution on how to interpret shortened
version names.

@scheibelp Would you like to self-assign?
@tgamblin for nagging. :-)