Аннотации времени компиляции на примере @Implement

Про инкапсуляцию не согласен. Валидность идентификатора зависит от внутренней реализации UnitManagerа и RotateCounter, который, кстати, я и использую в нескольких местах, ничего не должен знать об ее особенностях.

напрашивается паттерн фабрики.
вы указываете тип нужного идентификатора (строка, число, UUID, полоски зебры), отдельно указывается алгоритм проверки, что идентификатор свободен.
После этого любой из кирпичиков свободно вынимается и заменяется на аналог.
Но если так уж нужно иметь средство проверки именно в UnitManager… Если так?

interface KeyValidable<T> {
  boolean validateKey(T key);
}

class UnitManager implements KeyValidable<Long> {
   ...
   boolean validateKey(Long key) {
       //здесь некоторая логика
   }
}

не вгонял в компилятор, но суть примерно такая.
хотя мы углубляемся уже в евангелистику)

SOF — это Stackoverflow. тут опять же спор вечен. я лично больше люблю работать с ребятами, которые могут решить проблему разобравшись в ней по исходникам. Доходит до обращений к исходникам Jdk. Не могу утверждать, что готовый ответ плохо. При дефиците времени это даже спасает. Но ведь потратите вы час на изучение исходников или минуту на копирование строки — что запомнится?)

Eclipse-проект нельзя просто так взять и запустить в другой IDE.

ну вообще можно. но только предварительно установить специальный плагин нужно и в 90-95 процентах случаев все заведется)

Рефлексия это получение информации о типе на этапе выполнения. А это обработка на этапе компиляции.

У вас на этапе компиляции работает программа. Пусть и процессор. Все равно процесс есть.
Но частично согласен — это скорее из сферы плагинов и т.п.
Да и те же постпроцессоры спринга на рефлексию завязаны не слабо. А уж там ребята явно очень долго думали как бы обойтись без этого. И как видно не придумали.

При анализе метода в классе, тип параметра String, а в интерфейсе — T, и все попытки получить вместо него String не к чему не привели.

о! эта задача интересна) так просто не обходится.
возможно эта статья натолкнет на решение?

Тут кроме вкусовщины есть ещё как минимум две на мой взгляд важных детали.

1) При объединении реализаций нескольких интерфейсов в один класс сложнее понять, какая часть хранимого состояния объекта используется для реализации каждого интерфейса. Проще говоря — то, что при реализации через замыкание (через анонимный класс) могло быть локализовано в полях анонимного класса или в переменных порождающей его процедуры, в Вашем случае придётся вытаскивать в поля основного класса, замусоривая его.

2) Аннотации никак не уберегут Вас от конфликта имён, когда Вам придётся реализовывать два интерфейса с одноимёнными методами ) Даже получив нормальную диагностику об ошибке, придётся пересматривать именование методов.