А то. И с балалайкой :) А если честно, синтаксис первой версии шарпа сильно напоминал яву. Казалось, что облажавшись с J++ мелкомягкие пытаются хоть тут отыграться.

А какая логическая разница? неизменяемое значение и все тут. Разница в реализации в яве есть. Константы примитивных типов и String в ней инлайнятся.

Наверное решили что черт с ним, запрещать не будем, раз в классе можно, а использование в интерфейсе никаких механизмов не ломает.
Но зачем такое надо в интерфейсе... В обычных классах это достаточно полезная штука - логически сгруппировать что-то, или контейнер для нескольких полей, который больше нигде не нужен. В интерфейсе разве что как в в примере из первого сообщения - если хочется проинициализировать константы. Лично я такое не делаю и другим не даю - не надо мешать интерфейс и реализацию, потом какой-нибудь бедолага будет пытаться разобраться что тут понаделали, а главное - зачем.

А его не надо писать. Компилятор автоматически расширяет описание полей и методов. Пишется часто просто по привычке, пальцы сами public набирают.
Сделали так - методы всегда public abstract поля - public static final. Напишешь что-то другое - получишь ошибку. Хочешь явно написать - пожалуйста, не запрещено.

Вот тут не понял. Что запутывает и кто лепит?

Где-то так. На всякий случай, вдруг в шарпе поведение у const другое, хотя врядли понадобится, но на всякий случай...
Я уже упоминал что в яве "константы" примитивных типов (и строки) инлайнятся. Если чуть глубже копнуть, то это не совсем так. Инлайнится только те, поля, значение которых можно просчитать во время компилирования. Называют такие инициализации "constant initializer" или "compile-time initializer". Т.е. если есть final int x = 10; то компайлер везде обращение к этому x поменят просто на 10. А если final long x = System.currentTimeMills(); то везде ссылка на поле x останется, потому как во время компиляции компайлер не может посчитать чему будет равно System.currentTimeMills().