さきほどは，重くはならないよ，という，疑問への回答でした．
加えて，RTOS とバインドする積極的な理由を述べておきます．
理由はある程度の理詰めはあるものの，結局のところ「オレはこう思うんじゃい」という色彩が強く，別にそうしなくても軽量Rubyはベアメタルで動きます． 時間と予算が潤沢にあるなら，ね．
とはいえ現実は．
別段のファンドが獲得できているわけでもなく，取れる時間も限られ，加えて
過去の事例だとこの手のOSSは長期的には失われる結果になりそうです
という呪いまでかかった状態なので，素早くカタチにしないと，呪いが成就してしまうのでした．
大目標: ゆるふわ Ruby だけで，ガチ組み込み開発をしたい
すべては大目標の実現のためです．
＼ゆるふわ Ruby だけで，ガチ組み込み開発をしたい／ that’s all.
大目標(言い換え): ゆるふわでない Ruby で，ガチ組み込み開発をする気なんて無い
対極的な大目標として「mrbgems を全部削って，parser も削って，バイトコード実行だけできればよい．場合によってはバイトコードの命令セットも削る．」という設定がありえます． これもまた組み込み風味，いや，むしろ従来型の組み込みシステムっぽくて安全な気がします．
ですが，私はそこには寄り添いません． 先行事例が既にあるから，というのも理由の一つです． 加えて「そこまでするならCで書くわ」とミもフタもなく思うからです． コードゴルフをしたいなら，C言語を使えば良い．その用途ならばC言語は最強です．Ruby で挑む理由がありません．
さてはて，ゆるふわを極めるには，irb 相当の REPL がオンボードで動くことは必須です．
現実的な解として，ホストベースirbの実装が既にあります．私には思いつきませんでしたし，なるほどなぁと関心しきりです． なのですが，ホスト側にもソフトウェアが要る点で，私の想定分野では，重いなぁと思います． 昔の 8bit BASIC マシンやポケコンのようなゆるふわ感はありません．UART で繋ぐだけで REPL が立ち上がってほしい． (ホストベースirbの実装理由が「”ゆるふわ”にしたかった」なんてことは絶対に無いでしょうから，私がどう思おうとも，実装の価値がどうこうなる話ではありません)
先行事例の実装で十分な領域があるのは，アタマでは十分に解っています． 今ここに書いているのは，「ぼくがかんがえたさいきょうの」厨二病的な放言です．
ゆるふわガチ組み込みに必要なアイテム
REPL を内蔵するとなると，UART ドライバが必要です．USB-serial ならさらに良いですね．
さらに，”ゆるふわ” なら，何も考えずに Socket や File を使い出せないと嘘です． ファイルシステムやプロトコルスタックを載せたくなります．
きっと使う mrbgems も，中で malloc とかからループとかバンバン使っています．
うーん，”ゆるふわ”． でも，その環境で，ガチ組み込みをしたいわけです．
uClinux 載せるとか，ご冗談でしょう?
しかし，ファイルシステムとプロトコルスタックを，割り込みハンドラから書くのは… 書いている間に，呪いが成就しちゃいます．ねぇ．
RTOS とバインドする 3 つの理由
そんなわけで，monami-ya.mrb が RTOS とのバインドを推進する理由は概ね述べてしまった気がしますが…． ざっくりいって，理由は，3つあります．
信頼性の観点
仮にRTOSを入れなかったとしても，UART，タイマ等々の割り込み処理は書かなければなりません． RTOSと比べて自前で書いたほうが十分に高信頼であれば，書くのも悪くないでしょう．
ですが…．
TOPPERS や uT-Kernel を始めとして，有名どころの RTOS には，第一線の研究者やエンジニアが関わっています． 彼らが日々バグを潰し合っているコードのほうが，明らかに信頼できます．
(多くのRTOSでは，最小構成に UART ドライバを含みません． しかし，UART は初歩的なデバイスです．大抵の RTOS ではドライバのコードが提供されます．)
保守性の観点
RiteVMの実装はほぼ1つでしょうけれども，マイコンはARMで集束に見えているようでいて， いまだにたくさんあります．特にガラパゴニッポンでは．
ARMにしても，セミコン各社でペリフェラルに特色を持たせた結果，なかなか心折れる状態です．
RTOS の上に構築した場合，mruby より下の層を気にせずに保守できます．
保守可能な動作環境の狭さは，その上で動作するソフトウェアのシェアに響きます． 軽量Rubyは，クロスプラットフォーム動作がメリットの一つです． それのメリットを活かせないようでは，自ら潰しているようなものでしょう．
普及の観点
おそらく，最初期のユーザは
C言語で書かれた既存資産を活かしながら，mruby を使ってみたい
と言ってくるでしょう．
Rubyでの書き換えで発生するコストやRubyで実行したときの速度低下のリスクを考えると，保険をかけながらの導入をしたいと思うはずです．
mruby が動作するようなレベルのマイコンなら，既にRTOSを前提としたソフトウェア資産が存在するでしょう．
もし「全部をRubyで書き換えるかmrbgem化しないと，始まりません」と言ったとしたら，おそらくユーザは逃げだします．
ファーストユーザを掴めないなら，普及を考えるなんてありえないでしょう．
まとめ，っぽい何か
そんなわけで， monami-ya.mrb は，従来の mruby 開発者が狙っていたところとは若干違ったところを目指しています． でなければ，fork なんて面倒なことをする必要なんて，なかったわけですし．
私は，私が狙った分野には，2つの大きな需要があると思っています．
- Gainer – Arduino の系譜に続く流れ
- パラメタチューニングやデバッグ用のシェル(ブートローダ含む)の高度化の延長
私の実装が生き残れるか，というのとは，また別の話ではありますけれども．