Your explanation makes a lot of sense ... from the perspective of a compiler writer.
As someone who just uses the language though, the distribution of code between backend and frontend is unknowable. In this light the distinction between “public” and @Transient appears quite arbitary. They are both modifier-like-things, but are spelled differently.
You say that @Throws, @Strictfp, @JvmStatic etc would have to be modifiers rather than annotations in order to be consistent with this world view and I’d say … well, yes! Just like in Java! I’m not sure why it’d be over the top - is there some sort of modifier budget that isn’t apparent?
Annotations always made sense to me as a way for third parties to extend the language, but for language designers themselves to use such things is still an idea I’m getting used to (and yeah, I’m not a big fan of @Override in Java either … I’m not sure why it also couldn’t just be a keyword).
I realise that at the start of Kotlin there was a strong desire to unify modifiers and annotations. It’d definitely have been cool to make the language work in this way. But as modifiers turned out to have some technical advantages and that unification has not happened, we are left with this odd state where Kotlin has the compiler architecture poking through into the language design and a distribution of modifiers-vs-keywords that looks, to the uninitiated outsider, pretty much random.
I’m wondering if the resistance to converting more annotations into modifiers is a holdover from the initial dream of metadata unification?