2ЛП
Да! Именно так! Это - вопрос скорее религии, чем чего-то еще ;-)))

Так...
Все это весьма спорно. Мне думается, что применительно к данному топику не следует забывать еще про unique index(UserID, RoleID).

если сделать так:
t1(t1_id), t2(t2_id)
t3(t3_id, t1_id, t2_id)
t4(t4_id, t3_id, text) -- то все нормально
Если t4 зависит от t3, то получается, что t3 - самоценная сущность, и у нее должен быть собственный ключ... С другой стороны, если t3 не рассматривается как самостоятельная сущность, а служит только своей единственной цели обеспечить M:M...

t1(t1_id), t2(t2_id)
t3(t1_id, t2_id)
t4(t4_id, t1_id, t2_id, text) -- вот это уже нарушение как раз получается, если следовать тому топику - то это все построение или вырождается в
t1(t1_id), t2(t2_id)
t3(t1_id, t2_id, text)
или же t4 можно рассматривать как не зависимую от t3 сущность, которая существует наравне с t3 и, кстати, если есть t4_unique_index(t1_id, t2_id), вырождается в t3-подобие. ;-) Так же завися (или завиша ;-))) только от t1 и t2.
С другой стороны, действительно, в процессе проектирования t3-подобные таблицы имеют неприятное свойство "внезапно" становиться самостоятельными сущностями, поэтому себе дешевле заранее запланировать суррогатный ключ типа t3_id. Вот и вся религия.

2ЛП
t5(t4_id, t1_id, t3_id)

Так... А так делать не надо. С самого начала видно, что если t5 зависит от t3, то она уже зависит и от t1.
(Если вспомнить топик про нормализацию, получается, что если поля в индексе зависят от суррогатного ключа индекса, то это автоматом делает их связанными с таблицей, на которой этот индекс (и тогда вязать с t1 не надо), а если, как в том топике, ключ был не суррогатный, то указанного построения здесь и не возникает ;-)).
Вообще говоря, теорию мне тоже надо бы перечитать, но использовать суррогатные ключи я вряд ли перестану - даже если тем самым и буду рисковать нарушить 4НФ ;-)