引用：

知識の乏しいユーザーの一意見ですが・・・
EC-CUBE の移行（バージョンアップ）は例えDBの変更がなくても結構大変なので、敷居が多少高くなったところで、あまり差異はないように感じます。

それよりも、コミッターの方々が良いものと思えるシステムで EC-CUBE が構成されていく方が、今後の活性につながるのではないかと考えます。
（何が良いかは、わからないので突っ込まないでください。）

引用：

お忙しいと思いますが、勝手に期待させていただきます。

----------------
EC-CUBE3っぽいテンプレート
GitHub で公開中
https://github.com/bluestylejp

お問い合わせ番号CSV登録&メール送信プラグイン
http://urx.red/qDT6

> 今現在、2.11系がどの程度使われているのかってのが気になります。
> まだ新規案件で2.11を利用する勇気が無いので。

私どもの場合ですと、2.11.2 あたりから、ちょこちょこ使っています。

サイト数だと10+といった感じですね。(2.11 導入済みサイトのカスタマイズ含めて。うん、確かに新規案件では少ないかも。)

参考まで。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

ロジックのポリシーを理解していないため的外れな場合は申し訳ありません。

ツリー構造の放棄、維持では無く、規格に必要な情報の見直しは検討されていますでしょうか。
私の経験上、販売管理、債権管理、商品管理に関しては、
品番（又はJAN）、品名、価格、在庫数が串刺しになってさえいれば最低限の管理が行えると考えています。
サイズ展開、色展開等で同一品番（又はJAN）で管理を行う場合は、品名でカバーが可能になります。
この事から考えると、現在の規格が持っている情報は、便利ながらも多すぎるのではと思います。
項目が減らせない場合は、product_idに規格をぶら下げるのではなく、規格=product_idとして管理をし、product_idをグループで管理をするのはいかがでしょうか。

product_idを管理するグループをproduct_grpとした場合、オススメ商品、商品一覧、関連商品に表示させる商品はproduct_grpを参照させることで何か改善出来るのでは無いかと考えています。

実際のデータの持ち方としては、完全個別管理が行なえるように見受けられますので、まとめる事を考えました。

現在の商品、規格のインターフェイスや項目は登録のしやすさを前提に検討されているように感じますが、入力の手順に気をとられること無く、快適な挙動をご検討下さい。

規格によるサイトのレスポンス低下は、売上に直結するためサイト運営上非常に深刻です。
懸命なご判断を期待しています。

好き放題書いてしまいましたが、いつもありがとうございます。
そして、頼りにしています。
頑張ってください。