IMHO, each specific functionality of a node (maybe even each
message type), should have its own bit in the services field.
I'm talking about the 64-bit field that currently is always set to 1.
Using the "version" filed to indicate whether a node supports things like "getheaders", "ping", "mempool", "reject" or bloom filters - this is a mistake.
Currently you basically get to choose between version 6000x and 7000x, but the reality is never that simple.
For instance: the node I use does not support bloom filters (probably never will), but it does support things like "getheaders" or "ping".
And I wish my node could be honest about which commands it will reply or act upon, and which it won't, but with the current protocol this is just impossible to be honest about it.
All I can tell you is version 60002, 70001 or 70002 - and none of them will actually be correct.
My point is: if the folks developing the core could get advantage of the services field (which shall not be a hassle), I believe the protocol itself (and thus the network as a whole) would have benefited from it.
EDIT:
Also I'd like to point out that the service field (unlike the version filed) is sent along with IP inside the addr message.
So for instance if you have an SVP client, then you could just ignore all the nodes that are not going to serve the bloom filtering for you and never connect to them.