Three defects in the typed-buffer template (2026-07-07 review). All are latent-but-armed: the template instantiates for kv32, kv64, sha256, range32, u8cs, … and the only current bSplice caller happens to be u8.
Bx.h:435-438 bSplice mixes units: off, cut, $len(paste),
bDataLen are ELEMENT counts but applied to u8 *b as BYTE offsets and memmove sizes. Correct only for sizeof(T)==1; any non-u8 instantiation splices garbage while still advancing buf[2] in elements. Sole caller today: TLV.h:70 (u8) — works by accident.
Bx.h:388-393 bReMap non-mremap fallback memmoves old_size bytes
into a new_size mapping — OOB write on any shrink; this is the path macOS CI takes. Also MAP_SHARED vs the mremap path's private mapping. (Distinct from MEM-021's MMAP.c items.)
Bx.h:506-510 bAcquire: (1) aligns with sizeof(T) mask instead of
alignof(T) — garbage for non-power-of-2 T, and inconsistent with bAlign/bAren (Bx.h:451,483) which use alignof; (2) cap * sizeof(T) unchecked overflow → tiny sz passes the room check, child claims cap elements over a few bytes; (3) base + sz > arena[3] pointer-overflow UB. Same len * sizeof(T) overflow in bAllocate (:202), bMap (:369).
bSplice for a 4/8-byte T and splice mid-buffer;
a shrink bReMap under #undef MREMAP build; bAcquire with huge cap.
copy to min(old,new), alignof + overflow-checked size math.