This is an interesting sentence that I am having to re-read several times in context of the rest of your post. Trying to wrap my mind around it.
Care to expound/describe a little further? An example maybe?
I think your choice of the EAV is right on the money. The SQL Server types that I've come across have disliked it in certain circumstances because they have been focused on applications that are externally facing with 1000 of concurrent occasional users that have little or no focus on the system and every millisecond slower in returning values can result in lost user attention. I think with internal highly focused and educated employee users that are using the system every single day it is more important the system has the flexibility to allow them to keep detailed and accurate notes even if it slows down the initial pickup by users. The attention and focus of the users is much more channeled as they will be using it every day they quickly become very familiar with the UI.
I tend to do EAVs in two formats one being slightly more tied down than the other.
1st type
Three tables
tblEntities (in your case engineering product)
tblEntityAttributeValue ( with entity field being integer and being referentially linked to tblEntities - thats the FKID I am talking about
Attribute itself being a lookup referenced to tblAttributeLookup
Value being free form
tblAttributeLookUp
This structure encourages consistent definition of attributes (depending on how widely you give create access to the tblAttributeLookup). And helps minimise similar attribute variations
eg
Colour
Color
Remove access to tblAttributeLookup and enforce only allow options within lookup and you can really limit / frustrate your users...
2nd Variation
The alternative is the same but without the tblAttributeLookup and just allow Attribute in the Lookup table to be free form text rather than a lookup. This can be preferable in some cases where the attribute can give some background to the value.
With engineering products I suspect the first 3 table option will be slightly better.
I quite often use the more free form for storing web links.
Another alternative that is often used but not always called EAV is splitting into tables relating to the 'native' data type eg dates / times / numbers / money etc...
To my mind bank statements are like that my bank statement has little more than three columns description amount and date... Clearly in the background the entity is probably my customer number but it is being split into data type in this case money. That is almost exactly an EAV + date structure. From my above variants this would be a EAV of the 2nd variant as the attribute definition is very free form. We are really getting into the finer points of relational design I have called it EAV + date but it could be called EAVV but then what is a child table but an entity and then a number of values E+(V)n
So a EAV table where values are limited to dates.
An EAV table where values are limited to numbers (decimal or otherwise).
An EAV table where values are limited to text.
this can be useful when you have a stream of values that are extremely important to record accurately eg dates / times / moneys... and where you frequently need to do calculations on the subsequent information.