First of all, "synchronized", "volatile" etc are not part of the language, but rather hints to the back-end that facilitate interoperability with a platform.
Then, the fact that annotation targets are not checked by the compiler, and thus nobody controls where you can apply an annotation is a temporary lack of a definitely needed feature. For some annotations, like “inline”, some of these checks are in place already, for others they will come later.
Your reasoning is correct where it comes to “data”. In fact, those soft keyword that we internally call “modifiers”: “public”, “override” etc. could and probably will be turned into annotations as well, at least internally (the highlighting will likely remain as it is). The argument about square brackets falls into two categories: local declarations will always require square brackets around annotations, and the do not admit modifiers at all; all other contexts will eventually admit annotations without square brackets (when we fix a few parser bugs in this area).
Important note: all modifiers are soft keywords, i.e. you can name a variable “public”, it is not prohibited. In this sense these words are not reserved or anything, so they are very close to annotations indeed.
Bottom-line: you are right in that the division into annotations and modifiers is arbitrary. We will solve this by turning modifiers into annotations. The syntax will be fixed and the checks will be put into their place.
Why we prefer annotations:
- This is more flexible and easier to evolve: we might want to add a parameter to some annotation later on, this would not be possible with a modifier.
- Theoretically, annotations can be marked deprecated and retired over time. It’s a lot harder with modifiers.
- This is more uniform with user-defined things: if you want to write your own annotation-based framework or even a compiler plugin, the syntax will not look “second-class”.
- Annotations, being part of the library, require less work to integrate into the language, tooling, docs etc. There’s a uniform way of treating them, and again, it’s not different for user-defined things.