Would it be possible to add into the type system a representation of structs where some of their fields are inaccessible for some reason: there is an outstanding reference, its value was moved out, it was never initialized, or similar?
I imagine this would be a sizeable project, touching many parts of the Rust compiler. If this seems like a feasible approach, I can try to find a professor that would be willing to let me work on this for my Master's thesis.
The general idea is that an incomplete struct has the same memory layout as the full structure, but the inaccessible fields are uninitialized memory. Some efficient way will be provided to consume an incomplete struct and make a new full structure using the same memory; hopefully through normal compiler optimizations instead of special functions. It is illegal to construct an incomplete version of a structure that implements Drop.
A reference (mutable or not) to an incomplete structure, however, is statically prevented from accessing any of the other fields. This allows for functions that only need access to some of the struct's fields to operate safely on partially-initialized structs. It can also be used for an API that allows immutable references to one field at the same time as mutations to another.
One sticking point with the previous splitting-borrow proposals has been their interactions with traits. With this sort of splitting being inherently field-based, they could not be used in traits, which don't interact with fields. With this proposal, it should be possible to define a trait impl for a partial structure. This way, the type designer has the option to make two traits that are disjoint, so that mutable references to the two traits can coexist.
Another discussion item that often comes up is whether borrow-splitting should be an implementation detail of the compiler or an explicit annotation. I am attempting to dodge this question by allowing the type system to describe what people actually want to do (and probably some kind of fully-qualified syntax for it), which leaves the door open for future type-inference solutions to do some of this automatically.