Hi Stian,
First off: I didn't know that Keycloak existed three weeks ago. Much of what I write might be a result of me being unfamiliar with earlier design choices. That being said:
Based on the snippet that you provided I'd argue that it is the service, rather than the admin client, that could/should be improved. When implementing a (REST) service, it is common to provide a representation as part of the response to a create (POST) request: the service response should include the most up-to-date representation of the resource, which prevents the client from having to reconstruct it (exactly what you're doing in that snippet), which is tedious, error-prone and lacking the inclusion of server-generated values. On top of that, if a client needs multiple requests to recreate a representation, concurrency issues come in to play. Who's to say that all responses reflect the exact same state, server sided?
Restructuring the web services could lead to a large change (although inclusion of representation in responses might be backwards compatible, as the random sample of services that I checked appear to currently have empty responses - perhaps the representation could simply 'fit in'). In any case, timing-wise, such an effort would coincide with the upcoming 2.0 development.
Based on the above, my suggestion would be:
1) Apart from the changes above, there might not be a need to rewrite the admin client. From my basic use over the last two weeks, I like it's simplicity. It provides a low-level entry point for people that start with Keycloak, which is good.
2) I can't say - simply don't have enough experience in this fields. Then again, in Java, when one says "in theory, it's compatible" it typically isn't.
3) Apply the changes for the as-is client to 1.9.x, and improve services (and as a result, the client) in 2.x
Kind regards,
Guus