Is everything in the ielm run below actually OK or does it illustrate
bugs in the handling of bool-vectors?  It certainly illustrates
"features" that seem quite unintuitive.

===File ~/bool-ielm=========================================
*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (setq b1 (make-bool-vector 3 t))
#&3"" ;; Of course, ^G is 7, definitely no bug here.
ELISP> (fillarray b1 t)
#&3"ÿ"  ;; this is the character with code 2303 
ELISP> (format "%o" 2303)
"4377" ;; the last 3 bits are still 7.  b1 has length 3.  OK.
ELISP> (setq b2 (make-bool-vector 3 t))
#&3""
ELISP> (equal b1 b2)
nil  ;; this however looks strange to me.
ELISP> (setq b3 #&3"ÿ") ;; We set b3 to the printed representation of b1.
#&3""
ELISP> (equal b1 b3)
nil  ;; b1 is not `equal' to the result of evaluating its
     ;; printed representation.
ELISP> (equal b2 b3)
t
ELISP> (length b1)
3    ;; Yes, b1 still has length 3.
ELISP> 
============================================================

Comments:

I can understand that fillarray winds up filling up an array used for
internal representation with length larger than 3, but b1 starts out
having length 3 and after the call to fillarray still has length 3.
Intuitively, it would seem that there are exactly 2^3 = 8 bool-vectors
of length 3, but apparently not, there are a huge number of them, due
to differences in additional internal spots.  Bug?

`fill-array' is supposed to work (give sensible and expected results)
for arbitrary arrays.  That includes bool-vectors.  Actually, the doc
string says so.  C-h f fillarray:

fillarray is a built-in function.
(fillarray ARRAY ITEM)

Store each element of ARRAY with ITEM.
ARRAY is a vector, string, char-table, or bool-vector.

My comments again:

Does anything in this doc string suggest the above behavior?

Sincerely,

Luc.