Yes, that's also something adopted from the existing Smartcard world. Existing smartcards can contain different payment applications (for example in Germany the "Maestro" and the "Geldkarte" application on the same card). So the terminal can actively request one specific application within the Smartcard.

But as Mike correctly said, we have no pre-existing infrastructure to support. So decisions should only be based on what makes sense for the future.

I'm not sure about this. I've built several HCE test apps and tested them with readers (and other phones used as reader) but I did not notice any difference to using CATEGORY_OTHER (besides that the apps using CATEGORY_PAYMENT appear in KitKat's new shiny "Tap & Pay" menu).

You are free to implement whatever protocol you want. On the reader side you simply do a IseDep "connect()" and send your commands with "transceive()" (https://developer.android.com/reference/android/nfc/tech/IsoDep.html#transceive(byte[])). After sending the initial ISO 7816-4 "SELECT APPLICATION" command (see here for some ISO 7816-4 doc: http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11) which triggers Android HCE routing mechanism to route all following PDUs to your HCE app, you are free to send whatever you want.

Anything you send with "transceve()" on the sender side, will be received within your HCE application in the "processCommandApdu" method:

https://developer.android.com/reference/android/nfc/cardemulation/HostApduService.html#processCommandApdu(byte[], android.os.Bundle)

The only limitation is that you have a strict request/response model. The reader terminal (or the reading phone) sends a request, the HCE phone sends a response.