ヘッダーでファイルサイズを指定してMoodleはファイルを送信します．
ブラウザは指定されたサイズのデータを受け取ったところでファイルを閉じるでしょう（多分）．
もし，BOMの３byteが誤って送信された場合，そこからたとえば100byteのデータを送ったとして，BOM＋97byteを受け取ったところでファイルを閉じられてしまう．残りの3byteは行方不明．こんなことが起きていると思われます．
MoodleがPHPのrequire_once()命令でファイルを読み込む場合に，<?phpより前にある文字列はそのままクライアントに送ってしまいます．?>の後の文字も送ってしまいます．ヘッダーをクライアントに対して送った後に読み込まれたPHPファイルの<?phpより前，?>より後にこれらのゴミがあると，それを本来，送信したいファイルの一部として受け取ってしまった恐れがあります．本来のファイルを送信した後であれば支障は無いのですが．
勿論，MoodleにアップロードされたファイルにBOMが含まれていた場合はそれも含めてファイルサイズが計算されますのでBOM付きでダウンロードされるので問題はありません．でも，賢いテキストエディタはファイルの頭にBOMの3byte分のデータが含まれていれば，これはUTF-8ファイルだと勝手に認識するでしょう．そのファイルの中身が実際にはシフトJISだとしてもです．これがダウンロードしたシフトJIS形式のファイルが文字化けして表示されるメカニズムです．ダウンロードしたファイルの頭からBOMの3byte分のデータを取り除いたり，強制的に「このファイルはシフトIJISだっ」と指定できるならば，（頭の所に化けた文字列が表示されるものの）途中からは正しく日本語文字列が表示されると思います．お試し下さい．さくらエディタに強制的にシフトJISで開く指定ができるのであれば．
バイナリファイル（画像）が正しく表示されないのも同じ理由です．バイナリファイルの頭数バイトのデータを見てブラウザは，この画像ファイルだと拡張子やmimeヘッダーが主張している形式であるかどうかを判断していると思います．こちらのページの情報を信じれば，JPEGファイルの場合は，FF D8 FF E0...と始まるはずです．頭にBOMの3byteが紛れ込めば，EE EF BB FF D8 FF E0...となるでしょう．むむ，jpegと名乗りながらも頭がFF D8で始まっていないじゃないか，これを表示しようとしてブラウザをクラッシュさせようという悪意のあるデータファイルの恐れがあるから無視する，という反応に出るでしょう．
まとめると，誰かがBOMの３byteを送信しています．config.phpとfsconfig.phpでは無さそうですね（fs_moodleの設定表示で検査済みなので）．
何か他のmoodleフォルダ以下のファイルをさくらエディタやメモ帳で開いて保存していませんか？
ちょっとこれからmoodleフォルダ以下の全ファイルのBOMチェックをするPHPスクリプトを作成してみます．本日中に完成するかどうか分かりません．
まずはconfig.phpをバックアップした上で，moodleフォルダ以下を別のフォルダ名に変更（moodle2など適当に），新たにfs_moodleパッケージのmoodleフォルダ以下を展開して先ほどバックアップしたconfig.phpをmoodleフォルダにコピーして下さい．これで正しくダウンロードできるのであればmoodleフォルダ以下にBOMの混入したファイルが存在したという証拠（？）になります．
