Yes, minimal error handling of the strange cases is in place, e.g. multiple settings. Plus the access scope is mostly respected - so the recently discussed classes like NodeChildren will be gone.
There are some things which perhaps need further discussion. For Groovy classes I suspect people will be expecting 'public' to be missing. At the moment we still leave public on at the top most class level (perhaps we should turn that off - e.g. look at CliBuilder) but off for e.g. methods. Currently Java is done the same way but perhaps people expect the methods to be public as per normal Java conventions (e.g. look at a method in Expando). The isGroovy flag will help with this (but we also need a reference between members and the defining class - there is an incomplete hook for that already).
Just on overall design, I think there are two approaches we can take as we evolve Groovydoc further. One path we can take is to make the Java follow Groovy conventions. After all, why should I know or even care about what the base language is and won't getting rid of some of the noise assist making the Java easier to read? Perhaps, but it gives us no way to distinguish Java specific things like package private.
So, the other approach is to treat the two languages differently, which is mostly what we do now. For this to really work better, I think we need some more visual clues so that I can tell whether I am in Groovy and have something public or in Java and have package private. At the moment, it would be hard to tell. So, I think we need to work on that too. Perhaps some refinement of the CSS colors or perhaps a Java vs Groovy icon or some other indication on the page itself.