I was also going to include this as part of the UnitRelations.json:

"Length.Kilometer = FuelEfficiency.KilometerPerLiter * Volume.Liter -- NoInferredDivision",

but ended up reverting the change (not that it didn't work or anything). Here is how this would affect the two quantities:

    public readonly partial struct FuelEfficiency :
        IArithmeticQuantity<FuelEfficiency, FuelEfficiencyUnit>,
#if NET7_0_OR_GREATER
        IMultiplyOperators<FuelEfficiency, Volume, Length>,
#endif

    public readonly partial struct Volume :
        IArithmeticQuantity<Volume, VolumeUnit>,
#if NET7_0_OR_GREATER
        IMultiplyOperators<Volume, Molarity, AmountOfSubstance>,
        IMultiplyOperators<Volume, ReciprocalLength, Area>,
        IDivisionOperators<Volume, Length, Area>,
        IMultiplyOperators<Volume, Length, AreaMomentOfInertia>,
        IDivisionOperators<Volume, VolumeFlow, Duration>,
        IMultiplyOperators<Volume, EnergyDensity, Energy>,
        IMultiplyOperators<Volume, FuelEfficiency, Length>,
        IMultiplyOperators<Volume, ReciprocalArea, Length>,
        IDivisionOperators<Volume, Area, Length>,
        IMultiplyOperators<Volume, Density, Mass>,
        IMultiplyOperators<Volume, MassConcentration, Mass>,
        IDivisionOperators<Volume, SpecificVolume, Mass>,
        IDivisionOperators<Volume, Mass, SpecificVolume>,
        IDivisionOperators<Volume, Duration, VolumeFlow>,
#endif

Here are the pros and cons to consider:

• the multiplication operator seems reasonable: we multiply some amount (volume) of fuel by some fuel efficiency and get the travel distance. Technically there isn't anything wrong with dividing some length by a given fuel efficiency, in order to get the amount of fuel- however I don't immediately think of fuel efficiency as the result of dividing a length by volume (although I can't say I have any particular default quantity in mind 🤷 ).
• the downside (even with the NoInferredDivision) is that it binds the two quantities together, making it harder (if not impossible) to separate the Volume and the FuelEfficiency later (e.g. UnitsNet.Common + UnitsNet.Extended)
• as a middle ground, we could just add (by hand) the multiply and divide operators on the side of the FuelEfficiency, however this might seem odd w.r.t. the multiplication..

@angularsen A lot of important decisions for you to make in this PR 😄

PS Of course we could just close this PR: I don't care much either way, I had the json file changed while testing other stuff (from months ago), so one way or another I wanted to resolve my change-set..

@angularsen Ok, I've removed the MeterPerCubicMeter , skipped the tests and updated the PR summary to reflect the changes.

I've also updated the summary of the related issue: #1463, have a look at the remaining tasks..

the downside (even with the NoInferredDivision) is that it binds the two quantities together, making it harder (if not impossible) to separate the Volume and the FuelEfficiency later (e.g. UnitsNet.Common + UnitsNet.Extended)

I'm not sure I follow, how is this worse than binding to other quantities? Is it because you consider this a less-widely-used quantity?

Regarding extensibility and splitting up into packages, this is tricky with static typed stuff that we primarily deal with, but I have some ideas in #1500

as a middle ground, we could just add (by hand) the multiply and divide operators on the side of the FuelEfficiency, however this might seem odd w.r.t. the multiplication..

If the inferred operators don't make sense, then yes, we always have the option of manually adding them.

the downside (even with the NoInferredDivision) is that it binds the two quantities together, making it harder (if not impossible) to separate the Volume and the FuelEfficiency later (e.g. UnitsNet.Common + UnitsNet.Extended)

I'm not sure I follow, how is this worse than binding to other quantities? Is it because you consider this a less-widely-used quantity?

Yes, I'd say that the minimal quantity set (e.g. UnitsNet.Common) would have to include the SI quantities + all of their associated operators (e.g. Mass -> Density) + all of their associations (e.g. Density -> KinematicViscosity, DynamicViscosity etc..).. I haven't tested how many quantities would get covered by this graph, but If there are enough left-overs we could put them in a separate nuget.

Alright, I fear it will be tough to split up into two packages where one cannot depend on the other, but maye there is such a cut.