Gmail整理スクリプト改修

スマホを使い始めてからメインのメールをGmailにしているのですが、まあ、普通は一度見ると見返すことは無いですよね。ということで、たまる一方になるわけで、それを定期的に整理する（早い話が古いメールを削除する）ことをGoogle App Script（以下、GAS）で実行するようにしています。
これまで問題なく動いていたのですが、４月に入り（正確には4/2から）、正常に動作しなくなりました（まるっきり削除しなくなった）。休日なので、原因究明と可能なら対応をと考えました。

まずは本当に対象が無いかを確認。GASではGmailAppオブジェクトのsearchメソッドにクエリ文字列を渡して、対象となるスレッドを抽出するわけですが、その際のクエリ文字列を下記の様に生成していました。

label:○○ after:2018/11/10 older_than:1m -is:starred

内容は、ラベル「○○」（label:○○）の付いたメールで、2018/11/10以降（after:2018/11/10）で１カ月以上前（older_than:1m）のスターが付いていない（-is:starred）メールとなります。このクエリ文字列をGmailの検索窓に貼り付け、検索してみると、該当のメールがヒット。GASのGmailAppオブジェクトのsearchメソッドはクエリ文字列にヒットするスレッドの数を返すので、これが「０」となり、削除処理（=ゴミ箱へ移動）が実行されていないことが判明しました。
まずはキーワードからGoogle検索。検索結果を見てもいまいちピンとこない。そこで、AIモードで事象ベースで問い合わせをしてみました。様々な要因が挙げられましたが、どれも今回のケースには当てはまらず。
次に「クエリ文字列をGmailの検索窓に入れると出てくるが、GASでは該当なしとなる」とWebアプリとGASでの挙動の違いを入れてみました。一部、前回の質問と同じ回答がありましたが、ここでWebアプリとGASでは挙動が変わることが判明（Webアプリの方は「まあ、いい感じ」で処理するのに対し、GASの方は厳密な処理をするという）。

続けて、実際のクエリ文字列を使って問い合わせ。ここで結構大きな情報が出てきました。ここで得られた回答は、

1. older_than演算子の挙動
2. 日付形式の厳密性
3. 「スレッド単位」の排他制御（-is:starred）

まずは「older_than」演算子の挙動から。このolder_than演算子、WebアプリとGASとでは動作の安定性に差があるらしく、また、GASだとインデックスの更新タイミングによってはヒットしないことがあるとのこと。とはいえ、対象としたいメールが１カ月以上前に受信したものなので、これは可能性が薄いかなと思い、最後に確認することに。
続けて「日付形式の厳密性」。要は日付の区切り文字をスラッシュ（"/"）ではなく、ハイフン（"-"）にするというもの。これは簡単に確認ができるので、区切り文字を変えて動かしてみたところ、結果は変わりませんでした。
そして「スレッド単位」の排他制御。is演算子を使った制御になりますが、結論から言うと、これが原因でした（Geminiでも一番怪しいとしていました）。クエリ文字列から"-is:starred"を外したところ、GASでの結果とWebアプリでの結果（＝メールの件数）が一致しました。
この"is"演算子を使った制御ですが、クエリで絞り込んで得られたスレッドの中に、１つでも"is"で指定した条件に合わないものがあると、他の全ても対象外とするという、GAS固有の仕様だそうです。実際、Webアプリの方で実行した結果の中にスターが付いたメールがあり、これが原因で期待する動作（っていうか、4/2よりまでは期待動作だったのだが）にならなかったというわけです。
ということで、対策としては、クエリ文字列から"-is:starred"を外し、スター付きのメールについてはロジックで対応するということになりました。この修正により、残っていた削除対象メールを削除することができました。

しかし本当に突然でしたね。これまで動いていたものが突然動かなくなりましたからね。明らかに挙動が変わったので、仕様が変わっているのだと思うのですが、そんなアナウンスあったかなぁ？Geminiの回答でも挙がっているくらいなので、もう前からの仕様なのだと思うのだが、いきなりなったからなぁ。でも、is演算子の挙動、一つでも違うものがあるとご破算なんてことにしたんだろう？