結局、前回の内容を補強する経験しかできなかった。
SwiftUIは使えるレベルじゃない！これが結論。

まずは作ってる仕組みの説明
SwiftData(中身はSQLiteらしいが)を使っている。
画面は、下記の様な構成
データの一覧を表示↔登録・編集↔地図から位置情報を取得

使っている技術
データ一覧画面では@Queryで一覧のためのデータをSwiftDataから取得
登録・編集画面では@BindableでSwiftDataを更新
位置情報取得画面では@BindableでSwiftDataを更新
たったこれだけ、これだけで破綻してる。

実際に破綻する箇所についてだが、登録・編集画面で既存データを更新する。
更新後一覧に戻ると、一瞬だけ更新されたデータに基づいて表示されるが、即時編集前の情報表示に戻ってしまう。
更新がうまく行っていないのかと確認するとデータは更新されている。一旦終了させ、一覧を再表示するとちゃんと更新された内容で表示されることからも確認できる。
※その他にも確認ロジックを組み込んでリアルタイムでも確認してる。

これが特殊な複雑なパターン？？？
よくありがちな編集画面でしかない！
これで破綻する。どこが生産性があがるの？バグ回避のためにUIKitで作る場合の10倍の時間は使ってるが解決の糸口さえない。
こんなのを称賛してるのは、まともに開発経験がないのでは？と思う程に実用に足りてない。

では回避のためにやったこと…
@Queryをやめて、一覧画面表示の瞬間に最新データ取得、それをわざわざクラスを作ってそのインスタンス(@Stateで定義)で受け渡して。
つまりインスタンスのプロパティやらメソッドやらを動かしても再描画は走らないので、意図しない再描画は一切起こらないように制御してる。
登録・編集画面、位置情報取得画面では、受け渡されたクラスのインスタンスを使って更新データを保存して一覧画面でデータの更新を行う。
で、どうなったか…
型推論が破綻してコンパイルできず…型は出来る限り指定してるから本来なら型推論などほとんど必要としないコードなのに勝手にコンパイラが音を上げる。
項目数が多いだろと言われるかも知れないが、10ちょっとしかない。少なくとも多くはない。

他にも多く回避のためのコードを書き、試行し…
最初は、起こったバグに対しての回避コード、そこを直すと他のところにバグが出てまたその回避コードを…
この繰り返しを幾度となくやったけど、全く解決に至らない。
もし解決しても、Versionが変わったら再発も経験したし、はっきり言って使い物にならない!!!
ライフサイクルも保証されず、初期化コードを書くところもなく、結果無駄なフラグ管理を自分でやって、さらに他人が見たら意図不明は回避コードばかりが積み上がっていく。
これのどこが先進的で、生産性が高いの？疑問でしかない。もしそんなこと言ってるならApple関係者かもしくはチュートリアルで提示された例しか作ってないとしか思えない。
兎に角、もう最低限しか使う気は無い。

異論は受け付けますが、解決法を提示してからで。