История изменений

Скорее всего, потребуется иметь неподконтрольную GC кучу.

Вот да, в принципе сойдёт разделение памяти на несколько зон, типа:

• GC-куча для объектов без финализаторов/деструкторов, которые потребляют только память. Память освобождается когда удобно сборщику мусора. Циклы, глобальные ссылки и прочий треш-угар разрешён в полном объёме.
• RC-куча для объектов с деструкторами, которые могут держать и другие ресурсы. Вызов деструктора гарантируется где-то между исчезновением последней ссылки на объект и выделением нового объекта в этой куче. Допустим, даже можно иметь сколько угодно таких куч, каждая под свой тип ресурса.
  С циклами мне очень не нравится эта бредятина с ручной расстановкой слабых ссылок, но единственное вроде как рабочее автоматические решение — вспомогательный сборщик циклов — не сочетается с гарантией своевременного вызова деструкторов. Думаю, можно сделать и исключение для этого случая...
• Стек, для объектов со строгим scoped lifetime. Уничтожение объекта гарантируется при выходе из скоупа.

Интересные моменты — это могут ли объекты перемещаться между этими зонами, и можно ли создавать и хранить ссылки между зонами. Ах да, ещё одна штука: не выйдет ли так, что всякие контейнеры придётся плодить в трёх экземплярах.

Ну мне вот кажется, что финализаторы нужно вообще убрать. Как максимум, генерировать их автоматически, если есть поля не GC-типов или поля, для которых уже сгенерирован финализатор.

Мне вот тоже кажется, что финализаторы не взлетели. Во всяких С# и Java рекомендуют их использовать только для того, чтобы на всякий пожарный вызвать close()/dispose(). Но даже так, финализаторы тормозят сборщик мусора, так что нехорошо каждому объекту, реализующему IDisposable, выдавать неявный финализатор, просто потому что кто-то может натупить и не вызвать dispose().

Скорее всего, потребуется иметь неподконтрольную GC кучу.

Вот да, в принципе сойдёт разделение памяти на несколько зон, типа:

• GC-куча для объектов без финализаторов/деструкторов, которые потребляют только память. Память освобождается когда удобно сборщику мусора. Циклы, глобальные ссылки и прочий треш-угар разрешён в полном объёме.
• RC-куча для объектов с деструкторами, которые могут держать и другие ресурсы. Вызов деструктора гарантируется где-то между исчезновением последней ссылки на объект и выделением нового объекта в этой куче. Допустим, даже можно иметь сколько угодно таких куч, каждая под свой тип ресурса.
  С циклами мне очень не нравится эта бредятина с ручной расстановкой слабых ссылок, но единственное вроде как рабочее автоматические решение — вспомогательный сборщик циклов — не сочетается с гарантией своевременного вызова деструкторов. Думаю, можно сделать и исключение для этого случая...
• Стек, для объектов со строгим scoped lifetime. Уничтожение объекта гарантируется при выходе из скоупа.

Интересные моменты — это могут ли объекты перемещаться между этими зонами, и можно ли создавать и хранить ссылки между зонами.

Ну мне вот кажется, что финализаторы нужно вообще убрать. Как максимум, генерировать их автоматически, если есть поля не GC-типов или поля, для которых уже сгенерирован финализатор.

Мне вот тоже кажется, что финализаторы не взлетели. Во всяких С# и Java рекомендуют их использовать только для того, чтобы на всякий пожарный вызвать close()/dispose(). Но даже так, финализаторы тормозят сборщик мусора, так что нехорошо каждому объекту, реализующему IDisposable, выдавать неявный финализатор, просто потому что кто-то может натупить и не вызвать dispose().