Nice work Olin!  In fact Gambit-C is already almost 100% compliant with
SRFI 33.  Here are my first comments.

> Associative -- n-ary operators, for n >= 0
>   bitwise-and i ...
>   bitwise-ior i ...	Inclusive or
>   bitwise-xor i ...	Exclusive or
>   bitwise-eqv i ...	(not (i xor j))

This would be clearer:

  bitwise-eqv i ...	(lambda args (bitwise-not (apply bitwise-xor args)))

> Non-associative -- exactly two arguments
>   bitwise-nand  i j	(not (and i j))
>   bitwise-nor   i j	(not (ior i j))
>   bitwise-andc1 i j	(and (not i) j)
>   bitwise-andc2 i j	(and i (not j))
>   bitwise-orc1  i j	(ior (not i) j)
>   bitwise-orc2  i j	(ior i (not j))

I don't understand why bitwise-nand and bitwise-nor are not n-ary.

Also, this would be clearer:

  bitwise-nand i ...	(lambda args (bitwise-not (apply bitwise-and args)))
  etc.

> Trivial, hence not provided
>   bitwise-const0 i j	(lambda (i j) 0)
>   bitwise-const1 i j	(lambda (i j) -1)
>   bitwise-arg1 i j	(lambda (i j) i)
>   bitwise-arg2 i j	(lambda (i j) j)
>   bitwise-not1 i j	(lambda (i j) (bitwise-not i))
>   bitwise-not2 i j	(lambda (i j) (bitwise-not j))

Given that these are so trivial, I would suggest that they be included
in the SRFI.

> arithmetic-shift i count -> exact-integer
>     Arithmetic left shift when COUNT>0; right shift when COUNT<0.

Given that there is no logical shift, wouldn't it be better to call
this simply "shift" or "integer-shift".  I think the "arithmetic"
prefix is confusing.

> insert-bit-field  size position new-field i -> exact-integer

How about "replace-bit-field"?

Marc