Не сводится, прочитайте по внимательнее все 4 кейса использования. Для каждого из них вам придётся завести отдельный observable.

Настолько проще, что код написать лень?

1. В случае $mol_atom и lom_atom — может. Я привёл пример полностью рабочего кода.
2. В случае MobX там будет асинхронная установка.

Константа — это то, что возвращает сервер, а вернуть он может не то, что мы посылали. Так как вы реализуете 4 упомянутых мной сценария?

но если ни на эти observable ни на реакцию не осталось ссылок

В общем случае вы не можете это гарантировать. Например, если где-то в глубине computed свойств кто-то подпишется на любое глобальное состояние (например, на размер экрана), то такая реакция будет жить вечно и постоянно выполнять бесполезную работу. Поэтому лучше выстраивать все computed-ы приложения (а реакция — тот же computed) в одно большое дерево, которое чётко определяет какие вычисления ещё кому-то нужны, а какие — уже нет

Ваш код можно было бы переписать куда короче:

class Foo {

  @ $mol_mem
  data( next : any , force? : $mol_atom_force ) {
    const resource = $mol_http.resource( '/data' )
    return resource.json( next , force )
  }

}

Кода меньше, а делает больше:

1. Загрузка данных с сервера с кешированием: foo.data()
2. Перезагрузка данных с сервера с обновлением кеша: foo.data( undefined , $mol_atom_force_update )
3. Сохранение данных на сервер с кешированием: foo.data({ foo : [666] })
4. Пересохранение данных на сервер с обновлением кеша: foo.data( { foo : [666] } , $mol_atom_force_update )

Так и будете жить на устаревшей версии или планируете перейти на 4?

кроме fetch, но над ним можно сделать обертку, позволяющую записать его в псевдосинхронном виде

Лучше именно так и делать, чтобы происходила автоматическая отмена запросов, при уходе на другую страницу. Кроме того она позволила бы делать 1 запрос вместо 2, если на странице расположить два туду-листа.

Так и не понял на чём в итоге написали фронт. На первом Ангуляре?

Почему не сделать? Вполне можно точно так же обязать каждому вложенному компоненту давать уникальное имя в рамках владельца (вместо только лишь key для элементов массивов).

<div>
   <Panel id="buttons">
     <Button id="ok" />
     <Button id="cancel" />
   </Panel>
 </div>

А в селекторах писать:

Button — все кнопки
Select > #ok — кнопка ok во всех селектах
Select Button — все кнопки на любой глубине во всех селектах

И так далее

У IoC-контейнеров есть типичный косяк: он резолвит зависимости по типу. Но что если у нас есть 2 изначально одинаковые кнопки (Button), а нам нужно левую заменить на MyButtonLeft, а правую на MyButtonRight? Тут уже нужен не просто выбор по типу, а полноценный АОП с выбором по селектору, который может затрагивать: тип, локальное имя, порядковый номер среди братьев, глубина вложенности, специфический родитель и тд и тп. Пример с css селекторами:

@overrides({
    'Panel.buttons Button:first-child' : MyButtonLeft ,
    'Panel.buttons Button:last-child' : MyButtonRight ,
})

То есть сторонние компоненты вы не используете, ясно, только велосипеды.

Ну а к кому же ещё? Я обрисовал проблему, которая возникает при изоляции стилей. Как с ней бороться?

Ну а конфликты имён можно решать не только изоляцией, но и пространствами имён. А с ними имена классов получаются нормальными человекочитаемыми, а не недетерминированной полуабракадаброй.

У меня противоположный вопрос по css-модулям. Как мне в вышестоящем компоненте таки переопределить компонент на несколько уровней внутри. Есть ли что-то лучше, чем следующие костыли?

.date [class*="calendar"] [class*="day"] { ... }

Дерево компонент: Date > Calendar > Day

10 секунд — довольно быстро для "дойти до нужной директории, найти нужный файл, найти нужное место в файле не запутавшись в контекстах".

А были бы селекторы целиком — вы бы нашли искомое за пару секунд через ctrl+shift+f.

1. Когда правишь баги вёрстки — очень часто. Когда новый код пишешь, конечно ничего искать не надо.

   
   
2. Так многие (и я в том числе) уже отказались от препроцессоров в пользу css-next.

Специально для вас, кусочек типичного кода, который получается у средней руки программиста при попытке следования БЭМ-у и экономии на нажатиях клавиш (ведь именно в этом основное преимущество &, да?)

.panel-report
  min-width 700px
  height 100%

  &__head
    justify-content center
    align-content center
    min-height 40px
    margin 10ps
    padding 10px
    background $panel-head

  &__head-title
    color $panel-title
    text-align left
    max-width 50%
    padding 10px
    overflow hidden

    & > h1
      font-weight normal
      white-space nowrap
      padding 10px
      margin 0
      overflow hidden
      text-overflow ellipsis
      font-size: 20px

  &__wrapper
    width 100%
    display flex

    &--center
      .bench__blocks
        justify-content center

  &__blocks
    width 100%
    display flex

  &__block
    margin 10px
    border 1px solid $panel-border
    border-radius 4px
    background $panel-block-bg
    font-size 14px
    max-width 50%
    flex 1
    display flex
    flex-direction column

  &__title
    font-size 16px
    overflow hidden
    flex 0 0 60px
    display flex
    align-items center

    &--info
      cursor pointer
      user-select none

      &:hover
        background $hover-bg

        &:before
          content '['
          font-family monospace
          margin-left -1ch

        &:after
          content ']'
          font-family monospace
          margin-right -1ch

    &--text
        line-height 20px
        font-weight 600
        padding 10px
        color $panel-text
        text-align center
        overflow hidden
        text-overflow ellipsis
        flex 1 1 auto

  &__content
    padding 8px
    background $panel-value-bg
    margin 12px
    margin-top 0
    border 1px solid $panel-border
    border-radius 4px
    display flex
    flex-direction column
    flex 1 1 auto

  &__entity
    line-height 25px
    height 25px
    color $panel-text

    & > th
      font-weight normal

  &__entity-head
    vertical-align middle

  &__entity-row
    vertical-align middle

    & > em
      font-style normal

  &__power
    width 20px
    padding 0 6px

    &:after
      content '.'

  &__pos
    min-width 34px
    text-align right
    padding 0 6px

  &__name
    text-align right
    white-space nowrap
    text-overflow ellipsis
    overflow hidden
    font-size inherit
    max-width 180px

  &__val
    text-align right
    font-size inherit
    padding-left 8px

  &__br
    height 25px
    width 1px
    display block
    background $panel-border

  &__bar
    background-color $panel-bar-blue
    border none
    margin 0
    height 15px
    float left

    &.oil
      background-color $panel-bar-orange

  &__marker
    position relative
    margin auto
    cursor pointer
    flex 0 0 46px

  &__marker-indicator
    width: 34px;
    height: 34px;
    position: relative;
    background-size: 34px 34px

Все имена изменены, все совпадения случайны.

Сколько времени вам понадобится, чтобы найти место объявления стилей для следующего селектора?

.panel-report__title--info:hover:before

Ещё раз: проблема не в отсутствии обратной совместимости, что нормально для мажорной версии (16 раз за 4 года уже ломали апи или просто так счётчик накручивали?). Проблема в невозможности постепенного переезда. "Не правильные" и "недокументированные" методы использовались ведь не просто так, а решали конкретные задачи, которые без них, "правильными" и "документированными" методами было не решить. Те же "порталы", например.

Ну а аргумент "мы вам пол года кидали варнинги — почему вы до сих пор не обновили код сторонних библиотек?!?" — вообще мимо кассы.

А чем модификаторы хуже?