>  Он состоит из блоков, которые хорошо известны..

Я где-то заявлял обратное?

> S-1-5-18 - это SYSTEM, то же самое что и root.

Ваша первая ошибка в понимании аналогичных объектов в Windows и Unix. У root ID всегда 0, а вот у системных процессов он варьируется от 1 до 99. Рут всегда имеет права. System в Windows можно запретить доступ к объектам ФС.

> А потом их удалили, то что у вас будет на ФС?

Внезапно, в Posix-правах наличие пользователя/группы для заданного ID у объекта ФС, вторично. Файловой системе, ядру и окружению глубоко пофиг есть ли объект пользователь для которого задан ID. Я могу в правах на объект указать ID, которого нет в системе. Например, я могу для объекта доступного по NFS или WebDAV шаре на машине не в домене, из которого придет прльзователь, указать ID, скажем, 300185, зная что для доменного пользователя на на его машине доменный SID маппится в такой UID.
Для ACL - наличие объекта, к которому привязан SID, обязательно. Если его нет, я не могу задать для него права. А если он удален, то я не могу изменить права. При этом, если это права унаследованные от вышестоящего объекта, то я не могу вообще удалить объект, не слома ФС.

> Ну не принято удалять пользователей в каталогах, если в других частях инфраструктуры есть ссылки на них.

Вот именно из-за проблем с жесткой привязкой ACL к пользователю, удалять его "не принято". Так же как и не принято удалять построенное доверие между доменами, если пользователи поучали возможность создавать свои объекты в "чужих" сервисах.

> Вот тебе каноничный алгоритм:

Ничего, что этот алгоритм для объектов файловой системы работает не так, как для каталога?

> Во-вторых, наследование всегда имеет низкий приоритет.
>  они всегда пойдут во вторую очередь

Низкий приоритет имеет только, если противоположные права находятся на разных уровнях, например на уровне группы, в которой пользователь находится, и уровне пользователя из этой группы. А если для пользователя, который есть сразу в двух группах с противоположными правами, политики применяются случайным образом, Об этом сказано в документации MS раз пять или шесть. Для тупых выделено специально через особое привлечения внимания. И раз в пол года на форумах MSDN появляется тип, который не может понять почему у него такая проблема.
Для наглядного примера. Есть пользователь Вася, который состоит в группе "Друзья директора" и в группе "Пойманные за фаппингом на работе". Первой группе разрешено заходить в каталог "клубничка", второй - нет. Бедный Вася то имеет доступ к клубничке, то не имеет.

> то зачем тебе Deny-правила

Когда изначально права - все, что не разрешено, то запрещено, наличие deny-правил не нужно. Deny-правила появились во времена NT 4, когда ФС, имеющаяся у MS не знала запретов на доступ пользователя. И тогда было "все, что не запрещено, то разрешено". И только, когда MS сделала клиент для домена Novell, тогда они столкнулись с тем, что нужно добавлять разрешения "allow".

> Вся эта инфраструктура рассчитана на применение Kerberos

Изначально Kerberos предполагался для другого - для единой авторизации сразу на всех связанных сервисах. Проверку верификации SID внедрили только с в 2005 году. Именно по этому в Windows билет kerberos выдается после авторизации в домене, а не авторизация на ПК происходит после получения билета kerbros и идентификации пользователя.

> Ты имеешь в виду какие-то well-known учетные записи вроде NT AUTHORITY\NETWORK SERVICE, которые могут указывать на разные учетные записи в каталоге

Не на разные. На все учетные записи, по индивидуально. На этом была основана атака на сервер, если используется для авторизации LanManger или NTLMv1.
> Опять же, не вижу связи конкретно с ACL

Если ты убеждаешь систему, что твой SID валиден для доступа к объекту, ты получаешь доступ к этому объекту.И все из-за того, что allow понимается СИСТЕМОЙ по умолчанию.