What makes memory safety so important is that in C/C++, a missing bounds check on `name` gives you access to the entire heap, not simply the other fields within that allocation. Attackers aren't using missing bounds checks to look for `is_admin` fields in the same object. They're looking for a pivot to full memory control, so they can plug in their RCE exploit chain. So, the only time that attackers are looking for an intra-object overflow is if they have something like `struct { char buf[100]; void* ptr; }`, since that does lead to a pivot to full memory control. Fil-C protects that; you can't use that overflow to corrupt `ptr`'s capability.
This is why memory safety tech like MIE, MTE, and Fil-C focus on allocation granularity. If I wanted to support subobject granularity, I could; it's not a huge change to the capability model. Fil-C's first two capability models (back in late 2023, early 2024) supported subobject granularity. I'm choosing not to support it now because I understand the security implications well enough to know that it's not worth the complexity.
Fil-C started out as a macOS project. Fil-C supports Windows and macOS today via APE. Requiring recompiliation of everything is a luxury I can choose to support on Linux that results in memory safety of the whole process. If you find Fil-C useful and understand compilers, you could probably get a variant working that has FFI and then expose Windows and Mac API to it. You'd get something with a weaker safety guarantee, but no weaker than what you get today from Rust or Java.