>            (let ([bv (make-bytevector 36)])
>              (bytevector-u32-native-set! bv 32 offset)
>              (bytevector-u32-native-set! bv 28 (xid-id shmseg))
>              (bytevector-u8-set! bv 27 0)
>              (bytevector-u8-set! bv 26 (if send-event 1 0))
>              (bytevector-u8-set! bv 25 format)
>              (bytevector-u8-set! bv 24 depth)
>              (bytevector-s16-native-set! bv 22 dst-y)
>              (bytevector-s16-native-set! bv 20 dst-x)
>              (bytevector-u16-native-set! bv 18 src-height)
>              (bytevector-u16-native-set! bv 16 src-width)
>              (bytevector-u16-native-set! bv 14 src-y)
>              (bytevector-u16-native-set! bv 12 src-x)
>              (bytevector-u16-native-set! bv 10 total-height)
>              (bytevector-u16-native-set! bv 8 total-width)
>              (bytevector-u32-native-set! bv 4 (xid-id gc))
>              (bytevector-u32-native-set! bv 0 (xid-id drawable))
>              bv))))
>
> As can be seen, the expanded code is an overspecification of the
> original pack form.

Agreed.

> If the ...-set! calls were wrapped in perform it
> would allow the compiler to perform several optimizations:
>
>   - It would be possible to do evaluation order determination on the
>     whole block. In this example it would allow the compiler to first
>     emit the code for writing the constants and the variables, and last
>     emit the calls to xid-id when the register pressure is lower.

While this is cool, IMHO this example highlights the problem with the
specification: wrapping these in (perform ...) would imply that (xid-id
...) is re-orderable.

If side effects are later added to xid-id, that assumption becomes
false. (I don't mean to imply that you'd actually add side effects to a
record field getter, but imagine a big codebase full of procedure calls
inside (perform ...) blocks and it's not hard for mistakes to slip in.)

If "perform" is renamed to something that more clearly indicates it's a
low-level tool to be used sparingly, that's fine. My worry is that
people will sprinkle it casually around a codebase, oblivious to the
fact that it doesn't offer any safeguards.

Another alternative is something like (declare (side-effect-free
xid-id)) which can be placed closer to the definition of xid-id,
therefore more likely to be correct.

In general it's better if potentially dangerous declarations like this
are in their own sublanguage, as they are in Common Lisp.