One of the advantages with the BIP process is that it means that there are hashlocked descriptions of the specs available for people to implement against.

The BIP process is not the same as getting a PR accepted into core.  It is not a veto based process.  If you write the BIP and it doesn't have any serious technical problems, then it will be accepted into the BIP repo. 

Getting it marked as "final" is harder but I don't think that matters much.  I don't think that core would actually use a service bit that was claimed in a BIP, even if the BIP wasn't final.  Maybe in 20 years if thin blocks aren't being used, they might recycle it.  It would be pretty obviously an aggressive act otherwise.

The NODE_GETUTXO bit is a perfect example of that.  They don't think it is a good idea, but they still accepted the claim on the bit, because there are nodes actually using it.

On the other hand, the BIP git repository is hosted on the /bitcoin github site, so in that context it can be seen as linked with core.  I wouldn't be surprised if that specific objection was raised when it was moved from the wiki to github.  Luke may be willing to change that if you think that would be worth changing?

With regards to the proposal, the description on the forum link isn't sufficient for an alternative client to implement it.  I had a look at the thread and I think that this is the implementation?

https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b

Is the intention here to simply reserve the bit for thin blocks usage or to define the specification for inter-operation with other clients?

Perhaps there could be a process for claiming service bits as it can be useful to claim a bit in advance of actually finalizing the feature.

- Claim bit with a reasonable justification (good faith intent to implement and the bit is useful for the feature)

- Within 3 months have a finalized description of the feature that lets other clients implement it

- Within 6 months have working software that deploys the feature

- After 6 months of it actually being in active use, the bit is "locked" and stays assigned to that feature

There could be an expiry process if it ends up not being used after all.  Requiring a public description of the feature seems like a reasonable requirement in exchange for the community assigning the service bit, but we don't want to go to far.  There is no point in having lots of free bits that end up never being used.  Worst case, the addr message could be updated to add more bits.