I like how SBCL does it. Heap box addresses have their bit 0 set, which makes them odd and thus unfit for direct access. But real accesses are register indirect with offset, with odd offsets to get an even address. So each time you see an odd address offset in SBCL-generated assembly, you know you're dealing with a heap box. I can only surmise this was a deliberate choice to aid orientation when reading generated assembly. If so, somebody among the designers of SBCL has a heart for crazy people like me.
On the other hand, this may make it worse for aarch64 & RISC-V, which can have shorter encodings for loads/stores with an immediate offset that's a multiple of the operated-on data: https://godbolt.org/z/zT5czdvWc
One huge benefit of keeping boxed objects on odd values on the low bits is that you can implement addition/subtraction of the integers without removing the flag bit, doing the operation and then re-adding it, instead you can just add 2 values with the regular add instruction and then use it (since the lowest bit won't change). On the other hand having the pointer offset doesn't do much of a difference since heap values will often be accessed with an offset (and offset-load/store instructions are more or less for free in most cases so subtracting a one to an offset doesn't change the cost)
