Now, for issue "
Subscription Validation and Verification of Intent should use POST".
This has been pondered in the past, but technically the hub is not sending any data to the subscriber, but rather asking something, which is why the GET request seems more appropriate in the REST terminology. In the end, the benefit of using GET is also that we have different logic between verifications of intent and notifications, which is a nice feature and makes it easier to implement subscribers!
The scenario that you describe, where the subscriber changes the state of the subscriber on its end is one possible implementation... others (like Superfeedr) actually "persist" the subscription when we issue the subscription request. We mark it as "verified" when the verification of intent (but that does not change the behavior), and we later mark it as "functional" when we get a notification on that callback. This helps us quickly identify how "broken" a given notification can be.
Then, for issue "Specific content-type for Subscription Request".
The Content-Type of the subscription request applies to the supplied body of the POST request, not to the content of the hub.topic. So, unless you provide a BODY that's in a different format, you *have to* use "application/x-www-form-urlencoded".
That being said, we could very well imagine that the subscription request BODY is a JSON document, like {hub: {mode: 'subscribe', topic: '...', callback:'...', verify: 'sync'}}. If that was the case, the subscriber would need to use "application/json" as the Content-Type.
What you describe with application/pubsubhubbub+xml is certainly possible, but I don't see the need for it (it adds complexity because most HTTP libraries provide all the syntactic sugar to send "application/x-www-form-urlencoded" POST requests.
You also seem to have missed that PubSubHubbub 0.4 is now agnostic in terms of Conten-Type, so it would be rather odd to go back to a time where PubSubHubbub only speaks XML :/
I hope all this helps!
Julien