I'm assuming that you mean that the camera supports only 640x480 and 800x600.  There are two problems here:
1. Width and height are separate capabilities, but this example requires the values to be tied (the way they can in constraint application), so that you can't ask for 640x600 or 800x480.
2. The IDL defines width and height as ranges, not lists of individual values.

If most cameras are restricted in this way, we could introduce a 'Size' property with an enumerated set of values, but to handle this in the general case (where a) some cameras have ranges for 'width' and 'height' whereas others have only specific values and b) the ranges and values may be tied to each other) the syntax would have to be at least as complicated as that for constraints.   

One thing to do is to say that wherever a property is defined as a range, the UA can enter a list  of values.  So the camera would have Capability 'width'= "480, 600" and 'height'="640,800".  (A list of values is a kind of range.)  This wouldn't capture the interdependency of the values, but maybe apps will just have to live with the fact that Capabilities may indicate a superset of what the UA can actually do.

I may be mistaken, but isn't getCapabilities supposed to report back what the camera+system+UA can accomplish, not the raw output from the sensor? And I think we have also said that the UA is not allowed to make up data.

So in this example, I guess the UA could downsample, and thus support more resolutions (but none higher than 800*600).

I'm not convinced that extending the syntax as Jim proposes is warranted, although Cullen is correct that capabilities will show 

{width: {min: 640, max: 800},
 height: {min: 480, max: 480},
 . . .
}

Interestingly, for this specific example it will also show only one aspectRatio (either 1.3333333333 or 4/3, depending on our final syntax there), so in this case you can figure out what it supports.

Just to be clear, I don't think we necessarily have to be able to have an API that can express this, but we do need to say what an implementation should report in case like this.

The concept of "size" instead of separate "width" and "height" has been discussed before and not adopted, so no change to spec is warranted.

There should be an example of return values from the capabilities call that shows this (and I think height { min 480 max 600 } width { min 640 max 800 } makes sense, or even height { max 600 } width { max 800 } if system's willing to downscale).

Added example in pull request https://github.com/w3c/mediacapture-main/pull/35

While examples are nice, I would argue they're no replacement for specification.

Are capabilities accurate?

While it is possible to deduce from the applyConstraints algorithm [1] that capabilities are allowed to be a super-set of what the UA supports, I find no mention of this where Capabilities is defined [2].

I've read the definition a couple of times, and even though it uses the word "subset" four times in one paragraph, it still seems to equate what the capabilities read with what "the UA supports", which doesn't allow for capabilities to be either-or (e.g. super framerate OR super resolution).

I think it would help implementations if the spec stated that returned capabilities must a set or super-set of what the UA supports.

Are capabilities constant?

I find conflicting text on this in the spec:

"The UA may choose new settings for the Capabilities of the object at any time. When it does so it must attempt to satisfy the current Constraints, in the manner described in the algorithm above." [2]

vs.

"Source capabilities are effectively constant. Applications should be able to depend on a specific source having the same capabilities for any session." [3]

[1] http://w3c.github.io/mediacapture-main/getusermedia.html#dfn-applyconstraints
[2] http://w3c.github.io/mediacapture-main/getusermedia.html#capabilities
[3] http://w3c.github.io/mediacapture-main/getusermedia.html#terminology