Does each Product in fact have many Barcodes? I can see *many to many*
relationships to Specifications - i.e. there is a list of
specifications which each product must meet, and another table listing
how each product meets a particular specification...

Each product spans among several packings, each bearing its own barcode.

If you're assuming that all the data must be in one table in order to
generate a Report on that data, think again. It's perfectly routine to
base reports on a selective Query!
No doubt about that.

The user should not be messing with table design... period... unless
the user is the table developer. This applies to adding new tables,
and even more so to adding new fields! The user should work with you
to add a new table, or new fields, as appropriate for the business
need.
I don't mean messing with table design. I mean that if a user wants to store
recipe information in the database, and a table (form, report, etc) not
specifically designed for that exists, he will have to use a table with
'similar' format to store that info in. To make it simplier:
The specifications table has four fields: ID, SpecCategory (that looks up
from SpecCat table), Product (looks up from Prod Table), SpecValue (holding
the value)
eg.
ID SpecCategory Product SpecValue
1 netweight Feta Cheese 18 (kg)

Should he want to insert recipe information, with a little bit of
imagination he would add a 'recipe' category in the corresponding table and
the specs table would be something like:
ID SpecCategory Product SpecValue
2 recipe feta cheese goat's milk, culture (etc)

But that would be only for informational purposes because specs table was
not designed to handle recipes.

On the other hand, If I make eg. a recipes table: ID, Product(lookup),
Ingredient, quantity
What happens if someone wants to have a Loss of Weight field (which I would
have not imagined was needed).

Surpassing that, completely normalizing all the tables is giving me a
headache because the tables that need maintenance multiply!