Standardize, how features qualify to become a VB 15.x, VB 16 candidate

Since I'm under the impression, the resources for actually implementing new features to the VB compiler are kind of limited (lack of resources on MSFT's side, lack of knowledge and time for _high quality features_ (most of them marked as 15.x or 16 candidate) on the community's side), I'm wondering about the process of prioritization, and what "Candidate" in the VB case exactly means. If we know at this point that the resources are rather limited, that even those features which are currently marked at 15.x candidate will not make it all into the actual product, shouldn't we come up with some transparent prioritization system, so we as community contributors are not focussing on the "wrong" features to have a more efficient process?

I would hypothesize that people might think the probability that a feature makes it into the actual product if marked as 15.x for Visual Basic is comparatively high. I would guess, it is not. If would think, there is one feature - Interface methods - which will very likely make it into 15.x or 16. But what about the probability of the other feature proposals. Realistically.

So, concrete questions:

1. What exactly does it mean if there a feature is a 15.x or a 16. candidate?
2. How did they become such candidates?
3. Can the community influence the priority for the actual implementation, and how does dotnet/vblang reflect that?
4. If there were LDMs discussing those feature proposals (and the finding of candidates), could we get access to those protocols, as we have them in C#, so we'd know better what to concentrate on?

@AnthonyDGreen, can you clarify the process?

What do people think/want?