> This will cause a lot of indirect access

It causes strictly less indirect access if you store it as part of the string struct, as C++, Go, or Rust do.

But makes passing around the type challenging to do efficiently. I agree it was probably the wrong choice in the end, but given the information available at the time, it’s not clear to me there was enough data / reasonable way to predict what the consequences would be and which approach would be better.

It’s more clear today but that’s because we’ve had 20 years of data of various experiments and ideas like small string optimizations on modern architectures that didn’t exist 40+ years ago.

> But makes passing around the type challenging to do efficiently.

Doesn't seem to be much of an issue in practice, even when strings are 3 words wide (as is the case for C++ and Rust because their strings are mutable[0], Go's strings are not so only 2 words).

Especially as it's a good tradeoff for safety, reliability, gains you performances elsewhere, and allows slicing.

[0] Rust String specifically, &str is immutable and 2 words, C++17 added string_view but I don't know how large it is, or whether it's used much if at all

> This will cause a lot of indirect access

You can optimize the common case of string data following the header by encoding the fact in a bit of the length field.

E.g. if the length is odd (LSB = 1) then the next word contains the pointer to the string body, otherwise the string body follows the length field. Archs that lack tagged arithmetic would require a shift but at least that skips a memory read for the string data indirection.

I suggest looking at the string handling capabilities of 1960 hardware and the high level languages that were used to program them.