Are there any difficulties or pitfalls here, or is it just a fairly mechanical process that simply requires finding the time to do it?

If it's the latter, I'll start chipping away at it.

If it's the former, I could also have a go, if you brief me.

Should be completely mechanical.

Implementation would start with the following macros

And you can compare against what the standard library is doing for inspiration on implementing for T and &T. https://doc.rust-lang.org/src/core/ops/arith.rs.html#117-133

Once the major traits are implemented we can go hunting to see if there is anything else like Sub that needs extra impls.

Implementation would start with the following macros [impl_ops!]

Just to be sure: Are you suggesting to add the implementations of the reference versions, to the bodies of those macros?

I don't quite understand the pattern inside the macro. First we have this group of 4:

• ....autoconvert! ... AddSubTrait
• not_autoconvert! ... AddSubTrait
• ....autoconvert! ... AddSubAssignTrait
• not_autoconvert! ... AddSubAssignTrait

followed by another group of 4:

• ....autoconvert! ... MulDivTrait
• not_autoconvert! ... MulDivTrait
• ................ ... MulDivTrait
• ................ ... MulDivAssignTrait

Why is there an asymmetry between the AddSub group and the MulDiv group?

I apologize for taking so long to get to this. I'll look at the PR in a second to see what you've done so far. The original thought was to do something to the standard library and use a macro that accepts the type (T vs. &T) as a parameter.

The asymmetry is because multiply and divide allow for operating on the underlying storage type as well as the quantity. e.g. length * time and length * 3.0. Add/subtract require the same quantity on both sides of the operator. e.g. length1 + length2. The [not_]autoconvert! macros decide if the implementation supports operating on quantities with different base units.