With the promise from the EG that JDO 2.0 won't require bytecode enhancement, it gets a lot more exciting =) We're working on strong support for 1.0.1 in OJB (delayed for a year from the initial effort because, well, no one actually wanted it) and some recent discussions have fed some thoughts on it.
First, the query language. Gavin of Hibernate thinks it is abomination, and I completely agree that it is bizarre when you think you are querying a relational database -- but there is a key, you may not be. What JDOQL manages to do is define a query in terms of the Java object graph rather than the underlying data store. Yeah, O2 and its derivitives (OQL, HQL, EJBQL, etc) are more more elegant, but that is because functional weenies designed the original O2 ;-) JDOQL isn't as bad as I originally thought, and it might even grow on me to the point where I think in it instead of O2 for object queries.
Secondly, the client-side JDO api is bloody simple, and works well. The query facility is cleanly seperated from simple retrieval by identity (so if you really hate JDOQL you can pretty easily extend an impl to support different query systems), transactions are flexible and simply designed, and using it is straightforward. I like the client side, and apprently others do too -- most popular persistence systems work in the same way if you squint.
The only complicated part of JDO is the JDOQL queries (and I guess supporting the optional transaction semantics, but they are optional!) and as Thomas D. pieces together a good AST based parser and translater for OJB, I'm seeing how easy it would be to plug anything in as the back end. The JDO EG has, since the beginning, focused on persistence in general instead of persistence in relational databases. Sure rdbms's will remain the most common, but they are far from the only backend around.
With that in mind, I think I'd like to try to keep OJB's JDO implementation as free of OJB specific code (the PersistenceBroker or OTM backend) as possible -- the only thing that really needs exposure there is the query, the transaction, and the identity. If we can engineer it such that we can pass back the query AST (or accept a visitor and do AST traversal on the OJB-JDO side) and provide transaction and CRUD hooks it should be straightforward to use it as the basis to easily implement other backends. I know the original RI took this approach (you can plug OJB in as a backend to the RI thanks to some adapters Thomas M. did when the JDO spec was first released). In theory you could use this implementation to adapt XML:DB, Hibernate, or even Entity Beans pretty easily to use the JDO front end. The key is just the need for something to handle the state tracking, transactions-on-objects, and query parsing (you would still need to provide a visitor or be able to work with the AST to translate the query to your choice of backend though, so not a free lunch).