I think what this use case needs is a ManagedRawBuffer class, with a create method that takes an explicit alignment, like UnsafeRawBufferPointer.allocate. Ideally at the same time we'd add this we'd also flesh out the existing raw pointer APIs with e.g. new helpers to help figuring out alignments within such heterogeneous storage. (This would resolve problem #4 in the (only tangentially related) pitch I just posted in Evolution.)
Alternatively, we could provide standard ManagedBuffer variants that allow multiple Element types, but that could be difficult to do well without variadic generics.
If you only ever need to store a single SIMD16<UInt8> value, it is most likely a better idea to move it to Header, and set the Element type to something that holds one row of integers. (Say, UInt64, (UInt32, UInt16, UInt16), or an equivalent struct.)
If you have strict layout requirements for the integer rows, then representing them with UInt64 or struct imported from C are probably the best options.
If you need multiple SIMD16 values before the plain integers (or if you need to guarantee that the SIMD value is laid out immediately before the integer rows), then setting Element to SIMD16<UInt8> is probably the best you can do! You can then rebind the parts that correspond to the plain integer rows to one of the types above. Be careful when calculating the capacity of the buffer -- it will need some slightly creative accounting.