Portage can work with binary packages just fine: https://wiki.gentoo.org/wiki/Binary_package_guide

ChromeOS/ChromiumOS uses portage for its build system, to produce a signed, read-only image that the OS can boot from. CoreOS uses the same tooling FWIW: http://www.chromium.org/chromium-os/build

This is why you can’t just install random packages onto the parent OS. Any additional software needs to run in some overlay filesystem or sandbox.

I have never tried using portage with binary packages, but I am using Paludis with binary packages since a while and I have to say it is very different from using Apt or Pacman.

Package managers which are build for source packages (e.g. ebuilds/exheres) have a much more complicated logic running in the background, come up with much harder to solve problems and are a lot slower (orders of magnitude).

The only aspect where this setup is superior than e.g. arch + pacman is when it comes to using source packages on the same system. So I guess that is nothing you would like to use on a Chromebook anyway. Therefore, using a Debian container is a reasonable choice, in my opinion.

Do you know if pacman is available on Chrome OS? My understanding is that it's based on Gentoo but it's heavily modified. So adding a different binary-based package manager isn't that crazy of an idea, especially for Google.

Two package managers are a bad idea. They would need to cooperate somehow. Pacman developers probably have heard of Gentoo, but I wouldn't call it "based on Gentoo".

I meant that since pacman is not available, then use a different one entirely (not both). It seems it's a moot point b/c of the sibling comment saying the disk is read-only.

Chrome OS puts the core operating system on a read-only partition, which is why people have been using chroots in developer mode up until now.