Nyashプログラミング言語のハイブリッドアプローチ設計について相談です。

【ハイブリッドアプローチ提案】
前回の「静的メソッド vs Everything is Box」議論を踏まえ、実用性と哲学を両立する設計を提案します。

【核心設計】
1. **文字列リテラル = 箱化**: "hello" → 自動的にStringBox
2. **名前空間 = static class名**: StringBox.upper()で明示的アクセス
3. **インスタンスメソッド併用**: obj.method()も継続利用可能
4. **継承は特殊拡張のみ**: 基本操作は名前空間、特殊な拡張のみ継承
5. **nobox最適化**: パフォーマンス重視時のプリミティブ化

【具体例】
// Everything is Box哲学維持
local msg = "hello"                    // 自動StringBox化

// 名前空間経由（明示的・継承不要）
local upper = StringBox.upper(msg)     // "HELLO"
local len = StringBox.length(msg)      // 5
local result = MathBox.sin(3.14)       // 計算

// インスタンスメソッド（従来通り）
print(msg.upper())                     // "HELLO"
print(msg.length())                    // 5

// 特殊拡張のみ継承（継承チェーン問題回避）
box LoggedString from StringBox {
    init { access_count }
    override toString() {
        me.access_count++
        return from StringBox.toString()
    }
}

// 将来の最適化
nobox local fast_str = "hello"         // プリミティブ文字列
local optimized = StringBox.upper(fast_str) // 高速処理

【設計の利点】
1. **Everything is Box維持**: 哲学的一貫性確保
2. **継承チェーン問題回避**: 基本操作は名前空間で解決
3. **明示性重視**: StringBox.method()で何をしているか明確
4. **実用性確保**: いちいち継承しなくても基本操作可能
5. **段階的最適化**: noboxで性能チューニング可能

【懸念点・質問】
1. **二重API問題**: StringBox.upper() vs obj.upper() の併存は混乱を招くか？
2. **名前空間汚染**: 多数のstatic methodsがBox名前空間を占有する問題は？
3. **学習コスト**: どちらを使うべきかの判断基準をユーザーが覚える負担は？
4. **パフォーマンス**: 自動箱化のオーバーヘッドは許容範囲か？
5. **他言語比較**: このハイブリッド設計は主流言語と比較して自然か？

【他言語の参考例】
- Python: str.upper() + "hello".upper() 併存
- Java: String.valueOf() + obj.toString() 併存
- JavaScript: String.fromCharCode() + str.charAt() 併存

Nyashの哲学（明示性・Everything is Box）を維持しながら、実用的で学習コストの低いハイブリッド設計として成立するか、専門的見解をお聞かせください。