I think if someone wanted something like a ternary field, but you knew for some reason it was going to be restricted to always be a prefix mask, it would be somewhat clearer and more explicit to have a new match kind like prefix that could be mixed and matched with all other match kinds, but which required an explicit priority for each entry provided by the control plane when the entry was added. That would hopefully make it clearer that the winning entry had nothing to do with the prefix length.
The size property on tables is often taken in implementations I am aware of to be ‘up to this size, but perhaps less depending upon issues like the range implementation described, or hash collisions in multi-way hash table implementations of exact match tables, etc.’. Thus it is not really an easily determined predictable capacity, but an ideal one if things go well.
There are many classification algorithms often called “algorithmic TCAM” that do not use TCAM hardware, but implement similar classification methods, that are also usually quite unpredictable in how much memory they will use – it depends upon the precise set of rules you install.
On the nitpick question, I don’t think this is mandated by any P4 language specification – I would check with the vendor of your device if it matters to you.