ну да, я знаю. Я видел. Вопрос в том как он работает

нормально)

примерно вот так может работать 

So maybe things should work like this: when an &T and an &UnsafeCell<T> alias, performing mutation through the &UnsafeCell is UB, but both of these references existing is fine, and even performing a read through either of them is fine. So likewise, when an &mut T and an &mut UnsafeAlias<T> alias, this in itself is fine, but performing any kind of access via the UnsafeAlias is UB (due to violating uniqueness of the &mut T). That should work for generators, right? Basically, &mut UnsafeAlias<T> opts out of "eagerly" asserting anything about the location, and doing any kind of access is treated similar to a raw pointer access.
```

ну он не может работать нормально

ну ок

примерно вот так может работать 

>but performing any kind of access via the UnsafeAlias is UB (due to violating uniqueness of the &mut T).

здесь написано то же, о чём писал я выше

реализуя safe-интерейс мы не можем нарушать его инвариант

там точно так же не может откуда-то появиться две ссылки, если происходит мутация

таким образом нельзя сделать T & a cell.roref, а после изменить, либо получить мутабельную ссылку

Ну, ты же не будешь спорить что сафе интерфейс над unsafecell возможен и существует?

я понятия не имею что там за интерфейс. Я вот сообщаю о том, чем он являться не может

мне интересно две вещи. а) найду ли я хоть одного адепта, который что-то понимает. б) способны ли адепты что-то изучить и проверить

use std::cell::UnsafeCell;

let x: UnsafeCell<i32> = 42.into();
// Get multiple / concurrent / shared references to the same `x`.
let (p1, p2): (&UnsafeCell<i32>, &UnsafeCell<i32>) = (&x, &x);

unsafe {
    // SAFETY: within this scope there are no other references to `x`'s contents,
    // so ours is effectively unique.
    let p1_exclusive: &mut i32 = &mut *p1.get(); // -- borrow --+
    *p1_exclusive += 27; //                                     |
} // <---------- cannot go beyond this point -------------------+

unsafe {
    // SAFETY: within this scope nobody expects to have exclusive access to `x`'s contents,
    // so we can have multiple shared accesses concurrently.
    let p2_shared: &i32 = &*p2.get();
    assert_eq!(*p2_shared, 42 + 27);
    let p1_shared: &i32 = &*p1.get();
    assert_eq!(*p1_shared, *p2_shared);
}

Ладно - это было слишком просто. В очередной раз мы видим, что даже на первый взгляд адекватные адепты не способны к пониманию того, о чём они говорят.

т.е. оно так же не позволяет получить две ссылки.

use std::cell::UnsafeCell;

let x: UnsafeCell<i32> = 42.into();
// Get multiple / concurrent / shared references to the same `x`.
let (p1, p2): (&UnsafeCell<i32>, &UnsafeCell<i32>) = (&x, &x);

unsafe {
    // SAFETY: within this scope there are no other references to `x`'s contents,
    // so ours is effectively unique.
    let p1_exclusive: &mut i32 = &mut *p1.get(); // -- borrow --+
    *p1_exclusive += 27; //                                     |
} // <---------- cannot go beyond this point -------------------+

unsafe {
    // SAFETY: within this scope nobody expects to have exclusive access to `x`'s contents,
    // so we can have multiple shared accesses concurrently.
    let p2_shared: &i32 = &*p2.get();
    assert_eq!(*p2_shared, 42 + 27);
    let p1_shared: &i32 = &*p1.get();
    assert_eq!(*p1_shared, *p2_shared);
}

ты о чем, я  о гипотическом UnsafeAliasedCell который должен позволить решать вот такие проблемы
https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462
https://github.com/rust-lang/rust/issues/63818 не о каких 2-х "мутабельных" ссылках речи не идет

причём тут две мутабельные ссылки? Я говорю о двух ссылках - пусть хотя бы одна из них будет мутабельная

о чём написано выше. Там всё понятно.

самое интересное, что по ссылке написано тоже, что я объяснял я. Только там адепт всё перепутал

и родил  какую-то херню, которая не может работать. Т.е. он предлагает хакнуть кодоген и хакнуть инварианты safe