It am not sure if a flat list of features is an improvement. It does feel to me that there are categories along the lines of the original capability exchange and I would love us to follow along those. I think for now, I prefer the old categorization into server and client features.

The challenge is that now in Client Features, there is only one non-deprecated feature Elicitation

@dsp-ant we discussed this a bit in Core Maintainers. The problem with the current way is that:

(a) Client Features only has 3 things, and 2 of them are deprecated
(b) It's not really clear why they are "client" features any more in the MRTR world. They are things that the servers asks for from the client, but no longer client sent requests.

Not the end of the world, but IMO the client/server distinction is a bit confusing.

@pja-ant In my mind, these are still client features, as in functionality offered by the client. A feature doesn't imply how to request it (via a direct RPC call or via MRTR). For me that distinction is still important.

That we have 2 of 3 client features deprecated is unfortunate, but the distinction still stands. I certainly see a world where we add more in the future. We should own that we have very little client features for now. I delineate it by who is offering the capability.

If we feel that the separation into client and server features is confusing for users, that's okay, but I so far still prefer it.