Nyashプログラミング言語のBID-FFI ABI v0統合計画について、最終レビューをお願いします。

【背景】
- Phase 9.75g BID（Box Interface Definition）が野心的すぎて複雑
- 既存のFFI ABI v0仕様はシンプルで実績がある
- 両者を統合し、段階的に実装可能な設計にしたい

【統合計画の要点】

1. **Phase 9.75g-0: FFI ABI v0準拠（1週間）**
   - 型システム完全化：i32, i64, f32, f64, bool, string, array(T)
   - メモリモデル明確化：32ビットポインタ、4バイトアライメント
   - Effect system：pure/mut/io/controlの4種類
   - Box layout標準化：[type_id:i32][ref_count:i32][field_count:i32]

2. **実装の簡素化戦略**
   ```rust
   // Phase 1: C ABIのみ
   pub enum TransportType {
       DynamicLibrary,      // 最初はこれだけ
       #[allow(dead_code)]
       Grpc,               // Phase 2で追加
       Rest,               // Phase 2で追加
       WasmComponent,      // Phase 3で追加
   }
   ```

3. **文字列・配列の統一表現**
   ```rust
   // FFI ABI v0準拠
   BidType::String => vec![WasmType::I32, WasmType::I32], // (ptr, len)
   BidType::Array(_) => vec![WasmType::I32, WasmType::I32], // (ptr, len)
   ```

4. **段階的拡張パス**
   - Phase 1: ローカルC ABI（.so/.dll）のみ
   - Phase 2: ネットワーク対応（gRPC/REST）
   - Phase 3: 言語ブリッジ（Python等）
   - Phase 4: 未来技術対応（量子等）

【設計原則】
- **Simple First**: 動くものを最速で作る
- **FFI ABI v0互換**: 実績ある仕様に準拠
- **拡張可能**: TransportTypeで将来対応を予約
- **Everything is Box**: Nyash哲学を維持

【質問】

1. **FFI ABI v0準拠は適切か？**
   - 型システムの統合方針は妥当か？
   - メモリモデル（32ビット、4バイトアライメント）は現実的か？
   - WASMとネイティブの両対応は可能か？

2. **段階的実装は現実的か？**
   - Phase 1でC ABIのみに絞るのは賢明か？
   - vtableを後回しにして基本型のみから始めるのは？
   - 1週間でFFI ABI v0準拠は達成可能か？

3. **拡張性は確保されているか？**
   - UniversalConnectorトレイトは将来のgRPC/REST対応に十分か？
   - BidTypeは将来の複雑な型（Future/Stream等）に対応できるか？
   - エラーモデルは異なるトランスポートに対応可能か？

4. **実装の落とし穴は？**
   - 文字列の(ptr, len)表現で注意すべき点は？
   - Box layoutのプラットフォーム依存性は？
   - 既存のNyashコードとの互換性維持は？

5. **NyaMesh（P2Pライブラリ）との整合性**
   - 将来P2P通信もBIDで統一できるか？
   - TransportTypeにP2Pを追加する価値は？
   - 場所透過性の設計は適切か？

【期待する成果】
- 1週間で動くC ABIプラグインシステム
- WASM/VM/LLVMすべてで同じBIDが使える
- 将来のネットワーク対応への明確な道筋
- Everything is Box哲学の技術的実現

実装者（Rust中級者）が理解でき、確実に動作し、将来拡張可能な設計になっているか、専門的観点からレビューをお願いします。