FakeReads create inconsistent results with equivalent examples involving partial moves

The following code doesn't compile:

fn meow(mut x: (Option<u32>, String)) {
    let a = x.1;
    let f = || {
        let (y, _) = x;
    };
    f();
}

The error message makes sense:

error[E0382]: use of partially moved value: `x`
 --> meow.rs:3:13
  |
2 |     let a = x.1;
  |             --- value partially moved here
3 |     let f = || {
  |             ^^ value used here after partial move
4 |         let (y, _) = x;
  |                      - use occurs due to use in closure
  |
  = note: partial move occurs because `x.1` has type `String`, which does not implement the `Copy` trait

The closure uses x, so it's not valid if you've partially moved out of x. Well then, in that case, doing the partial move after the closure has already been constructed should probably invalidate it. However, this compiles:

fn meow(mut x: (Option<u32>, String)) {
    let f = || {
        let (y, _) = x;
    };
    let a = x.1;
    f();
}

Now, I don't think this is necessarily an inconsistency that must be eliminated. It's a pretty niche issue. However, we must have a reasonable explanation for why this happens and documentation from which this behavior could be predicted.

Meta

rustc --version --verbose:

rustc 1.87.0-nightly (f280acf4c 2025-02-19)
binary: rustc
commit-hash: f280acf4c743806abbbbcfe65050ac52ec4bdec0
commit-date: 2025-02-19
host: x86_64-unknown-linux-gnu
release: 1.87.0-nightly
LLVM version: 20.1.0

Start by compiling both equivalent examples with the reported nightly rustc version and compare their borrow-checking behavior and diagnostics. No source file or test is named in the issue; done means explaining why the ordering differs and documenting behavior that can be predicted from the language rules.