Here are my criticisms :
1) LoC doesn't indicate complexity. When you're looking at a code base and you see that it's 65000 lines, that by no means should be an indicator of whether or not a re-write is easily feasible -- especially with a filesystem.
2) Language shouldn't be a motivator for a re-write without considering why the language offers advantages, the end users don't care about which file extension is littered across the source tree.
Both of those tendencies (one to re-write everything in your favorite language, and two to come across with an idea that you understand how complex a mechanism is simply from LoC) indicate to me, anecdotally of course, a certain lack of experience; and I have a hard time imagining someone with those concerns tackling a re-write of a filesystem that gains 'the audience' any benefits.
If it's just for the sake of personal toys and fooling around with your own machine I feel as if those motivations are fine, but I have concerns if 'a new filesystem in Rust' comes from what I view as shaky initial motivations.
Look, I'm as into cool FS-hacks as anyone, but writing a new filesystem has 99+ problems and the language used is either the last of them, or it isn't even in the set.
Granted, you could (on Linux) write a little pseudo-filesystem (e.g. /proc or /sys) and not face any of the issues involved in extN or btrfs etc. I didn't get the sense that this was what the OP intended, but I could be wrong.
Many of the worst bugs (data loss and corruption)? Probably.
Having something like the Rust borrow checker around to make sure you don't make dumb mistakes is handy, to be sure. But, let's not oversell it as some kind of panacea. I bet I could write a FS in Rust with all kinds of bugs, and the borrow checker wouldn't be able to stop me.