I disagree. I strongly prefer having commands be explicitly registered instead; then subcommands could be handled in a much neater, and infinitely nestable, fashion:
Tiny commands could also be specified inline with this syntax.
Yes, this example uses Java 8 features (why are we still using Java 6 which went EOL over 1.5 years ago?), but it could be reproduced easily in Java 6 with a bit of boilerplate. Also, the interface-side code would remain the same; only the plugin would need to be built with Java 8 for the pretty version.
Aside from that, see my reply to the issue for some other reasons on why I believe that to be preferable over the annotation way.
We are not going to have annotation support in the interfaces. There is no need for them to be part of the interfaces for you to be able to use annotations.
If you want annotations, you can create a class to generate CommandCallable classes to dump into a Dispatcher.
In an old fork of my Bukkit plugin, I made a command system which had some nice features.
It did automatic parsing for sub-commands and some basic parameter types. It also did auto-completion for sub-commands and for parameters expecting player names or world names.
I’m not saying it’s a perfect design or implementation, but you may be able to get some inspiration from it.
I really support the Intake design. I was designing my own system to be very similar, but Intake is pretty much what Id like to see it look like anyways.
I think a more important question is how this works with what Mojang is doing. Both Mojang comamnds and the command block syntax. You need something in your command API for that.