character set database = latin1
character set server = latin1
character set connection = utf8
character set client = utf8
対応している文字コードとして、utf8はないので、ｕｔｆ８の文字コードをそのままujis環境で使うことになるかと思います。utf8_generic_ci がそれにあたるわけではない、ということなんですよね（？＿？）
4.0系だとcharsetのSQLは対応してないんで、この設定はあんまり関係ないですね。ここら辺になってくるとさすがにパンク。
えーと、おおよそその通りですね。
ちょっとレベルが高いはなしですねぇ
対応している文字コードとして、utf8はないので、ｕｔｆ８の文字コードをそのままujis環境で使うことになるかと思います。utf8_generic_ci がそれにあたるわけではない、ということなんですよね（？＿？）
ただ、それだと文字情報までは失わないのでは？（推測ですが）
というのは文字が■や▲に化けるのはわかるのですが、? ? ? ? ?に変換されているようです。
文字コードは、euc-jp(ujis)でphpmyadminから確認したら文字化けってことですか？
4.0系だとcharsetのSQLは対応してないんで、この設定はあんまり関係ないですね。ここら辺になってくるとさすがにパンク。
それで吐き出されたSQLは日本語で表示されました。
で、補足なんですけど、調べてみたらoscはMySQL内部で文字化けしてました。orz
サーバ立てた業者訴えてやりたいです（怒
まいったなぁ。糸口が見えてきませんね、はは...皆さん引っ張りまわしてすみません。
進捗がありしだい、書き足していきますので、お時間がある時に突っ込んでいただけたらうれしく思います…
けど、そーなると部分的にOKだったりNGだったりってのがつじつまが合わないんですが・・・。だから、DBでもなく、php.iniにもこれといった問題もなく、land.toで同じ現象(こちらは文字情報までは失わず)になってくることを考えるとMODx側のロジックに問題があるのでは...？と思ってしまします。
ロジックってどこを仰っているのかわかりませんが、基本的にはコンテンツもシステム設定の情報もファイルの場所は別々ですが、やっていること（プログラムロジック）はほぼ一緒なんですよね。
実際、echoを追加したときも、結果を吐き出したのも部分的だったし...SQL書き込み時にすべてあのロジックを通っているわけではないということですよねぇ？？
リソース/ユーザ関係は、何も表示されませんでした。というのも説明不足でして、ドキュメントやMODxの設定は保存すると、 SQL= と出力されますが、
そもそものHTMLソースが実はUTF-8じゃなかった（ブラウザからみたら正常に見えるけど） ってオチは・・・・なさそうですね。多分
ブラウザのエンコードがutfで(っていうか、MODxの概観の設定でutfになっていたら、ブラウザもutfだろうし、MODxの設定にてサイト名を書き込んだら、それもutfになになりますよねぇ...多分(汗))