最初はパターン修飾子uなのかな，と思ったのですが，これは（Perl非互換の）正規表現に含まれるマルチバイトの取り扱いであって，置換対象文字列の文字コードのことではないですね．
Latin-1やCP932で文字列を扱う箇所が皆無とは言いがたいのですが，ＯＳに依存するかなり低位な箇所です．たとえば日付をdate()で取得する箇所は，日本語Windows版PHPですと”年”，”月”，”日”や曜日などをCP932（シフトJIS準拠）で返します．でもこれは早々にUTF-8に変換してその後の処理に取り掛かるべきです．Excelから取得したデータにしてもUTF-16LEからUTF-8に変換して処理していたはずです．標準のMoodleであれば英語版WindowsでLatin-1なファイル名は使用できない（アンダーバーに置換）はずです．SCORMファイル（ZIP圧縮）の中のファイル名にシフトJISを含むものがあったり，PowerPointをレッスンに取り込む際にトラブる話も本件とは別次元です．
海外でも，意外とWindowsServer上でMoodleを運用しているサイトがあるようですね（フォーラムは活発です）．そのようなサイト上で日本語のWikiコンテンツなどがMoodle2.0へのアップグレード時に破壊されるのが容易に想像できます… いまはset_locale(LC_ALL, ''); とすることでサーバOSの持つロケールを自動的に取得する（Windows版PHPのみの機能のようです）ことにしていますが，Linux同様に，get_string('locale', 'langconfig'); で取得するように変えてもイイのじゃないかな？と考えています．副作用は怖いですけれども，逆に副作用から問題点を炙り出すべきなのかも知れませんね．