looks good, but I think Memory<T> and ROMemory<T> should be marked as well.

Span needs to be readonly so that ordinarySpan.CopyTo(stackallocatedSpan) would work.

For regular structs being readonly is not functionally important. Since they cannot contain references, they do not participate in escape analysis.

That said, it is a good to have thing.
It is beneficial to mark struct readonly for perf reasons though. How much benefit will depend on the usage, but there is no downside.

On the other bug, I mentioned that threshold is the size to be > 2 or 4 pointers. I was confusing that with choice whether to use pass-by-value vs. pass-by-readonly-ref.

There are no unwanted consequences, however, in making a struct readonly (other than future compat issues if struct needs to drop readonly). Otherwise readonly struct behave exactly the same as ordinary structs and in some cases compiler can skip making defensive copies.

FWIW, I expect we're going to want to go through the BCL and mark many structs as readonly if they can be.

Right, ordinary-->readonly is not a breaking change.
(intentionally, so that existing structs could be made readonly too)