This "bytesmode" approach is ridiculous.

> The most straightforward fix would be widening `hfsc_sc.m1`/`m2` to
> `u_int64_t`, but that changes `struct hfsc_class_stats` which is
> copyout'd via DIOCGETQSTATS. While OpenBSD rebuilds kernel and
> userland together, the ioctl struct change ripples into pfctl, pftop, and
> any third-party tools reading queue stats. It also felt like using
> a sledgehammer.

Disagree strongly.

Right now, OTHER CHANGES are going on which will force everyone to
update their kernel, their userland, AND their packages in
syncronization.

And over the 6-month release upgrade, compatibility does not exist.

There are thousands of innovations in OpenBSD which would not have been
possible at all, and others would have bloated the source tree like your
diff, and this would have been impossible for our small team to perform
if we felt constrained by the argument above.  Small incorrect decisions
in the past always get made and in our group we CAN address them with
the cleanest rewrite, and compatibility arguments cannot require us to
create two modes, then three modes, then four modes, and expect us to
ensure the code has no bugs created as a side effect.

Therefore we only consider the binary cross-over issues enough to
understand if they are serious or non-serious.

The type must change.  Since it can become a 64-bit variable on 32-bit
architectures, modifications to the variable must be carefully checked
for atomicity problems.