Идея расширения модификаторов доступа

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

в Scala возможностей разделения видимости больше, там можно явно указать на каких именно уровнях будет он виден. в данном случае можно было бы написать private[system] для видимости в пакете com.system и ниже но не выше.

Для решения указанной вами проблемы предназначены Netbeans RPC, Eclipse RPC/OSGI, и Jigsaw который введут в java 7. При этом программа разделяется на модули и в каждом модуле указываются видимые из других модулей классы. На излишнюю видимость внутри модуля можно не обращать внимания.

По моему разумнее было бы поzволить подпакетам видеть то, что в дефолтном доптупе пакета.
А то (если принять Ваше предложение) при добавлении еще одного подпакета которому нужно видеть Ваш класс, придется модифицировать класс — добавлять еще один VisibleIn

Можно сразу отметить, что в ООП эта идея не нова, предложенный метод — почти полная аналогия ну, например, «друзьям» в C++. И подходит, пожалуй, больше всего для законченных наборов классов, для какого-то целостного API. Иначе, как верно сказано выше, будут проблемы как минимум с расширением (добавлением, модификацией, и т.д.) у сторонних разработчиков. В Java потому и нет тех самых «друзей», потому что здесь это заменено на пакеты и дефолтный доступ. И предполагается, что классы-друзья просто должны лежать в одном пакете. А идея глобального friend-доступа, возможно, во многих случаях понадобится, но пользоваться всем этим, как мне кажется, надо с осторожностью, иначе можно внести ещё бОльшую путаницу.

Посему интересно было бы услышать, в каких случаях с точки зрения автора были бы полезны данные аннотации. Что именно это даст? Примеры использования и т.д.

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

Подобные вещи умееет, например, OSGi. Одно время мне это казалось полезным, сейчас я склонен считать это малонужной опцией.
Во-первых: ну залезет кто-нибудь, ну сломает… Кому хуже-то?
Во-вторых. Пусть делается что-то замкнутое, с небольшим количеством внешних интерфейсов и богатой внутренней жизнью, за которую и страшно. Чего бояться? Что пропихнут через интерфейсы что-то лишнее? Так от этого всё-равно надо защищаться и отнюдь не дефолтной областью видимости. Или что попробуют повторить эту богатую внутреннюю жизнь за пределеми нашего уютного модуля? Так это не автора модуля проблемы, ну убьётся кто-то об стену, разбегаться-то сам будет.

Поддерживаю коментарий barker
Идея автора реализована в C++ friend'ами. Имхо, это в привносит путаницу (если ими пользоваться), к тому же надо изменять исходный класс, если надо добавить нового «друга».

Есть другая идея — разрешить доступ к членам классов в родительских пакетах и, возможно, в подпакетах. Модификатор для этого можно было бы оставить «по умолчанию», а можно ввести новые.