In the general term you should think on your requisites for these three things, and the pros/cons of the options provided Drupal core/contrib to accomplish them:

1. How to create and maintain the hierarchy of terms
2. How to select the hierarchy when creating/editing products
3. How to filter products based on this hierarchy related criteria (views or programatically filtering)

The way you decide for the 1st point (1 hierarchical vobcabulary or two related vocabularies) determines the options available to solve the other two points.

When using one hierarchical vocabulary, the most important thing IMO is to preserve the lineage: when classifying a product as strawberry, also classify it as a fruit). This is very helpful to address cleanly the 3rd point without a frustration neither inelegant approaches. Drupal core doesn't provide a way to preserve the lineage when creating product nodes. There're several modules out there that ensures it. The most powerful, Hierarchical Select.

Also, editing the hierarchy of terms with the core interface is a bad UX when you go above a few dozens of terms. To improve this there're modules like Taxonomy Manager.

Lastly, eventually you may face scale problems is the vocabulary is huge.

OTOH, using two vocabularies brings other pros/cons.

On the pros side:

• Configuring different fields in each of the vocabularies. For example, in the first level vocabulary (usually called family) a boolean field indicating whether the product is perishable, and a image field in the second level vocabulary for a photo of the variation.
• Preserving the lineage is not an issue, since you are selecting values in two different field/widgets that you enforce to be required.

On the cons:

• You're on your own with two independent vocabularies/fields that needs to be dependant somehow. You may want to create entity reference fields from parent to child, or the other side. You also need a dependant selector widget, ventually you want this widget to work also in views exposed filters,...

The Reference field option limit is great for this setup. It is a bit hard to get how it works, and it has some issues (specially I remember problems with i18n) but it does it pretty nice.

In conclusion:

• None of both approaches works 100% out of the box
• In the one-vocab approach you want to solve the lineage problem
• Two vocabularies is more versatile
• Two vocabularies is harder to setup

In the general term you should think on your requisites for these three things, and the pros/cons of the options provided by Drupal core/contrib to accomplish them:

1. How to create and maintain the hierarchy of terms
2. How to pick terms from the hierarchy when creating/editing products
3. How to filter products with a criteria based on this hierarchy (views or programatically filtering)

The way you decide to go for the 1st point (one hierarchical vobcabulary or two related vocabularies) determines the options available to solve the other two points.

When using one hierarchical vocabulary, the most important thing IMO is to preserve the lineage: when classifying a product as strawberry, also classify it as a fruit. This is very helpful to cleanly address the 3rd point without frustration, neither with inelegant approaches. Drupal core doesn't provide a way to preserve the lineage when creating entities. There're several modules out there that ensures it. The most powerful, Hierarchical Select.

Also, editing the hierarchy of terms via the core interface is a bad UX when you go above a few dozens of terms. To improve this there're modules like Taxonomy Manager.

Lastly, eventually you may face scale problems if the vocabulary is huge.

OTOH, using two vocabularies brings other pros/cons.

On the pros side:

• Configuring different fields in each of the vocabularies. For example, in the first level vocabulary (usually called family) a boolean field indicating whether the product is perishable, and a image field in the second level vocabulary for a photo of the variation.
• Preserving the lineage is not an issue, since you are selecting values in two different field/widgets that you enforce to be required.

On the cons:

• You're on your own with two independent vocabularies/fields that needs to be dependant somehow. You may want to create entity reference fields from parent to child, or the other side. You also need a dependant selector widget, eventually you want this widget to work also in views exposed filters,...

The Reference field option limit is great for this setup. It is a bit hard to get how it works, and it has some issues (specially I remember problems with i18n) but it does it pretty nice.

In conclusion:

• None of both approaches works 100% out of the box
• In the one-vocab approach you want to solve the lineage problem
• Two vocabularies is more versatile
• Two vocabularies is harder to setup