Sidenote: I wonder if a language could be developed that allowed the programmer to define or setup their own set of constraints around lifetimes and references. Sort of like what Zig seems to allow for memory allocator/allocation strategies, but specifically for ownership semantics. As I type this out, I can’t shake the feeling that this is basically what Rust has already done with their & vs &mut vs Box vs RC vs RefCell etc.
Yep to all of your post ... and this is my impression too (without having gotten on top of the smart pointers yet).
Only thing I can imagine adding though would be an optional garbage collector (that is shipped in the binary like with Go). I'm not sure how helpful one would be beyond RC/RefCell (I'd imagine a good GC could handle a complex network of references better, which wouldn't be very "rust"-like, but expanding the scope of the language toward "just getting stuff done" territory would be the main point of a GC). A quick search turned up this project which seems to be very small but still active (interestingly, the blog post linked there points out that rust used to have a built in GC but removed it to be a 3rd party library instead).
Re: lifetime notations, it’s good to know that this helped you. For me it was the combination of encountering the particular part in chap 4 of The Book where they examine the case of a function that accepts a tuple and returns a ref to the first element (or something along those lines), and trying to define (and then use) a struct that would store a ref to some other data in a hobby project.
Yea for me the structure and framing of The Book when lifetimes were first brought up (in Ch 4) didn't work for me as it came off to me as another series of problems to solve or constraints to navigate.
What I find interesting and compelling about the framing in my top post is that it conceptualises references and borrowing by starting with lifetimes. I'm not as experienced as you and haven't internalised rust like you have (awesome to read though!), but I think I would have found it better to go from the basic idea of pointers as a way of not taking ownership and then going straight into "everything has a lifetime with changing permissions/locks over that time depending on what other references exist and while rust infers these lifetime durations sometimes, sufficient complexity requires you to specify them yourself" and then building out from that basis. For instance, I'm not even sure The Book makes it clear that Rust is inferring variable lifetimes automatically (??).