トリガーやアイテムの設定は、再起動は不要です。

おっしゃっているトリガー側の判定条件については、
◆CPU負荷　などのように、
　「取得してきたデータが定期的に登録される場合向けのチェック」
◆イベントログ　などのように
「出力されたらそれが登録される場合向けのチェック」
があり、今回の問題点は、２番めのほうに該当しているのが原因です

基本、トリガーの「問題があるか否か」の判定処理は、下地となっているアイテム側への新規データ到着時にしか実施されません。

CPU負荷等のチェックの場合は、１分おき等、定期的に
新しいデータが届くうえ、チェック用の判定処理も「last()」などとなっています
そのため「登録済データの最後の値がいくつだったら‥」みたいな判定をするので、
アイテムに対して、データが収集されたあとにトリガーを登録しても、正しく判定されます。
おおよそ問題を感じないのはこのためです。

対して、イベントログやログファイル系（log等）の判定の場合には、話が変わってきます
先述のとおり、「新規データ到着時にしか、トリガーの条件判定は実施されません」

ログチェック等の場合には、１度収集されたログは再度収集されないようになっているため、
一度、エラーと判定されてしまうと、次の新しいログが出力されて、ZABBIXサーバに登録され、
正常と判定されるまで、エラーになったです

同じように、一度正常と判定されてしまうと、次の新しいログが出力されて、ZABBIXサーバに登録され、
エラーと判定されるまでは、エラーのままになります

今回、問題になっている例では、時系列的に

１）アイテムを登録
２）トリガー（TEST3）を登録
３）アイテムにログデータが登録される
４）トリガー３の判定が行われ、エラーと判定される
５）トリガー（TEST2）を登録
６）その後、新規データは届いていない

という流れだったのではないでしょうか？

再起動後には、両トリガーとも、「エラー」判定になった、との
ことですが、「再起動時にだけ」は、直前に登録されたログデータを基に
再度条件の判定を行うようにコーディングされているので、
エラーが発報されたのだと思います

いかがでしょうか？