タクソノミーの活用

1について

Taxonomy Term Reference Tree Widgetについては、Maintenance status: Seeking co-maintainer(s)となっており、バグがたまる一方であまり改善されてないようですので、このモジュールを使っていくことはちょっと難しいかなと思いました。
D8版もリクエストあるも厳しいかもですね。
フォークするか、自作（業者さんに作ってもらう）するしかないですね。。。

＃2　親系統のデータについて
入力登録時は、なるほど、基本的にはチェックをつけてもらって、その親系統を全部検索して、全部チェックをする動きをさせ、同時にその系統親のIDを関連で保存しておく、というのがセオリーと理解できました。

表示時は、タームのIDを関連としてでしかデータを持っていないのに、その（複数あるかもしれない）タームの系統親を全部関連するというように、プログラム上ルールを作るというのはよろしくなさそうですね。

今やりたいことは、
タクソノミーとタームを、複数選択させるために主にチェックボックス等で利用するときに、
カテゴリーの考え方と、データの扱い方のルールを要件定義しています。
原則がわからないと、混乱するので、教えていただいている次第です。

例えば、
ツリー構造の途中のあるターム、つまり下のタームからすると親のタームになるのですが、
食べ物＞くだもの＞みかん
くだもののタームは入力時には選択できないようにして、食べ物とみかんは選択できるようにする、

選択できないようにしたものは以下のグルーピングの分類メモ的（プレースフォルダー的）に利用する
みたいなことできないのかな、やっちゃっていいのかな
、です。
このとき、みかんだけを選択しても、みかんは実質食べ物だから選択されていなければならないし、
食べ物を選択しても、みかんとは限らない
みかん以外にその他を作る場合、みかんと同レベルに作った方が良いのか、
その他を作らなくても、食べ物を選んで、みかんではないので、その他であるということにした方が良いか。

この辺のまずの標準的な考え方や定石を知りたいなと思ってます。

タグはレベルが一般的には同レベルで（あまり階層などで複雑に管理しないスタイルや、木構造の場合複数系統にまたがって存在したい＝階層の場合は異なる親を複数持つ　）利用すると思います。
タグ新規に作られて登録された場合、管理側ではタグの整理を階層で整理しておこう、つまり、紐付けされるコンテンツの整理分類の役割と、タグ自体の管理分類の役割があっても間違いじゃないのではないか、ということをどうしてもやりたいです。

なぜならタグやタームが膨大になる利用をしたいからです。

本来ならば、管理用のツリーでタームを管理しておいて、実際に使うカテゴリーは、つど管理されているタームから任意に選んで構造化してツリーをセットし（これがDrupalでいうところのボキャブラリ）、そのタームの扱いもセットごとに違いような、
マスターデータとセットデータのような、
コンテンツタイプクラスとコンテンツタイプオブジェクトをいくつも作成するように、わけてカテゴリを管理運用できる機能を発注しようかなと思っています。