SEGV_MTESERR is reasonably low hanging fruit until it's in a binary blob and the IC manufacturer said service interfaces with refuses to do anything to fix it.

Likewise if it's because a language is being lazy with how it handles memory (see: wireguard-go SEGV_MTESERR because golang's string implementation was being overly permissive with pointers).

And of course this only applies to SEGV_MTESERR. SEGV_MTESERR has a much higher runtime overhead that Google and co would not tolerate (but Graphene does) so they'd likely only be willing to use SEGV_MTEAERR which provides traces that point at a completely different place than where the fault occurred (but still provide a little bit of useful info).