Ａ．ＢＩＮＤ９のＡＣＬ（Access Controll Lists）の癖となります。詳しくは[[https://kb.isc.org/docs/aa-00723|参考文献]]をお読みください。
というのは不親切なので、解説すると、

 1. ＡＣＬの処理はリストの左から右へ評価されます。これはＡＮＤ結合であるということを意味しません。
 1. よってブール論理で解釈するのではなく、ファーストマッチ・ファーストアウトで解釈する必要があります。
 1. 接続元ＩＰアドレスに対して、以下の３つが判断されます。
   * match and accept（一致かつ受諾）
   * match and reject（一致かつ拒絶）
   * no match（一致しない、なので次のリストに委ねる）
 1. これは「!」（reject）と「 」（accept、「!」が指定されてない）のニュアンスが直感的に違うことを意味します（今まで一致・不一致に見えませんでしたか？）。
 1. ネスト（{･･･}）されていた場合、その内容について下記の２つの評価を行い（ここでは一致・不一致の直感とマッチする）、その結果に対して上記３つの判断が実施されます。
   * match（一致）
   * no match（不一致）
 1. 当然ネストの中に更にネストできるので、それは上記２評価（match または no match）の繰り返しとなる。

上記ルールを踏まえ、問題のルールを解析すると･･･。

 * 大枠は２つのリストに分かれる（「!」の意味に注意）。
   1. !{ !ＩＰｖ４アドレス; !ＩＰｖ６アドレス; any; } → match and reject
   1. key "ＴＳＩＧキー名." → accept or reject
 * 最初のネストを分解すると、３つのリストに分かれる。
   1. !ＩＰｖ４アドレス → 一致した場合「no match」という評価で完了
   1. !ＩＰｖ６アドレス → 一致した場合「no match」という評価で完了
   1. any → 一致（常に一致する）した場合「match」という評価で完了

上記をまとめて解釈すると、

 * 最初のネスト内では以下の評価を行う（「!」の評価に注意）。
   1. 「ＩＰｖ４アドレス『ではない』」の評価をする。
     * 指定された「ＩＰｖ４アドレス」であれば「no match」として評価完了。
     * そうでないなら「match」として次の評価。
   1. 「ＩＰｖ６アドレス『ではない』」の評価をする。
     * 指定された「ＩＰｖ６アドレス」であれば「no match」として評価完了。
     * そうでないなら「match」として次の評価。
   1. 「any」（任意の全てのアドレス）に･･･とここまで来ると常に match と解釈され、評価が終了する。
   1. また any の時点で既に、「match」評価されてるので、この場合の「any」の指定のあり／無しに意味はない
     * ※人間の直感には反するから入れておいた方がいい。
 * このネストでの結果を全体「!」＝match and reject で評価することから、「no match」（つまり次のリストの評価）の時は、次のリスト key が評価される。