Really the client (and any generator) is expected to be done by the community. Mulesoft as far as I know is helping with some of it, besides the RAML spec, this site, and other things, they have some people dedicated to RAML that I know of. If you think of what Swagger has done.. most of their stuff is all community contributed. The problem with waiting on the community is everyone has different ideas of how a generator should be implemented, and what it should produce. There is no one project that aims to generate all the SDKs, CLIs, documentation, tests, etc. Even if there was, given the community process, it would probably still require quite some time to get groups of people to meet/chat/email one another and come to some agreement on the direction of the generated output, language to write it in, etc. For a spec like RAML or Swagger, thats a pretty big undertaking.
Having said that, while I am largely a Java (and like to think NodeJS) developer, I really really like the idea of using Golang as the primary generator project. That it compiles on any platform and for any platform, native code, and is from what I have been told and reading up on a kind of uber language of Java, NodeJS, C and C#, it just seems to have all the right elements to produce a solid RAML to ?? generator. To that end, I think Matthews project is very promising. I have asked that he is able to break out the parser to its own project at some point, and if I was confident with Go and able to help, I would love to dive in on his project right now. So take a look at his tool, and see if you can maybe help with that.
Another good project is the RAML2HTML. It is almost 1.0 capable.. although it is a doc generator. Me personally.. I would love to see a single tool, specifically Mathews toold, become the standard tool that we build generators off of.. and that includes doc generators, language generators, etc. This would fit well with my idea (that I responded to here (http://forums.raml.org/t/back-end-behaviors-where-to-describe-specifiy/1615/3) in having a way to provide a common set of annotations that generators would all agree (or try to agree) to support. Things like deprecation, HATEOAS, and more wild ideas could be handled in one tool (at least parsing) in a manner that add on generators could take advantage of more easily.
What I would REALLY like to see though, is some sort of consortium/community agreement on the direction of generators. The problem I have with the central Swagger generator is it is a crap shoot of whoever decides to work on it.. and every generator has different output capabilities. Some support the full spec, some a subset of it, some dont work well with parts of the spec, some ignore things in the spec they shouldnt. Most seem to be one off developed projects out of some need, that often seem to eventually lack support and/or continued improvement and fixes. And somehow, companies seem to jump on board with this idea of using Swagger because they have all these code generators they can provide SDKs and such with. No thank you. Give me a set of generators that put out good code in different languages that are all at the same completion level. Same with documentation output, tests, etc.
Anywho.. I do hope to see @Matthew_Baird project become the primary way in which we generate SDKs, CLIs, docs, etc in the near future and more people will jump on board to help him with that.