WebServiceHost woes in Orcas Beta2

Been playing around (actually, trying to get real work done) with shiny new Orcas Beta2 bits. I've been working on Orcas since the day Beta1 came out, and I've been eagerly awaiting the integration of WebGet/WebInvoke and full-fledged JSON serialization that Steve Maine's been talking about for Beta2. There are a couple of weirdnesses:

Steve suggests the use of WebServiceHost when hosting a WCF service that uses the new JSON stuff and WebGet/WebInvoke, because it wires up the right behaviors for you and checks a few other constraints (like only supporting one contract per endpoint address)... Turns out it also creates some new problems.

The enableWebScript endpoint behavior is what turns on all the JSON goodies. By default, WebServiceHost wires up a POX-emitting WebHttpBehavior (of which WebScriptEnablingBehavior is a subclass) on every webHttpBinding endpoint. It doesn't check first to see if there's already a webHttp behavior there. Looks like this means that if you want JSON serialization in B2, you have to use a vanilla ServiceHost and wire up the enableWebScripting behavior yourself. Otherwise, if you try to use a DataContract on a WebGet operation, you'll get the following InvalidOperationException on the .Open() call:

"Operation 'Bla' in contract 'Service' has a query variable named 'v' of type 'BlaDataContract', but type 'BlaDataContract' is not convertible by 'QueryStringConverter'. Variables for UriTemplate query values must have types that can be converted by 'QueryStringConverter'. Unfortunately, WebServiceHost hardwires webHttpBehavior on all webHttpBinding endpoints."

It looks like this won't be a problem forever: Reflector shows a WebScriptServiceHost that automatically plugs in enableWebScript (thanks, Lutz!), but it's marked internal. IIS users can probably use the WebScriptServiceHostFactory in a .svc file (since that's public), but I'll stick to the standard ServiceHost for now and just make sure I follow all the rules.