I think you're wrong there. See [1].
It doesn't use custom browser builds, but specific versions of official builds of mainstream unbranded browsers (you can also use branded ones if you wish). There are no "custom headless builds". All browsers support headless mode, and you can use it on your main browser by passing a CLI flag.
The reason it officially supports only specific versions is because there may be slight incompatibilities with the Chrome DevTools Protocol in each browser version, so they suggest running supported versions only. But like a sibling comment mentioned, you can also connect it to any existing browser instance, and, assuming there are no CDP incompatibilities, it will likely work.
Back in Windows-heavyweight app land, it made way more sense to interpose a low overhead shim to intercept and copy events.
I can't imagine the pain you'd encounter trying to paper over the other way around.
They do make some tasks tricky to handle, like tracking state, or avoiding race conditions, but in reality events are a good fit for interacting with browser DOM events, representing browser activity, and being able to react to it.
Consider the complexity of an average modern web site, that loads dozens of scripts, uses a frontend framework, is highly dynamic and interactive (likely a SPA), contains multiple frames, etc. All of this happens concurrently, and the only abstraction that makes sense to represent it is an event-based system. You can't achieve the same level of responsiveness using a traditional request/response protocol.
This is why modern browser automation protocols are event-based, and built on top of WebSocket. Selenium is pushing for WebDriver BiDi, while the browser standard is the Chrome DevTools Protocol.
Fully agree then. The only sane way to handle browser automation is by exposing all of them.
If it can only drive its internal browser engine, that'd possibly be a big argument against it for any test strategy I was architecting. I'd want the tests to be portable and usable cross-browser for acceptance--particularly UI-driven E2E tests, since that's really the only time they are critical.
The era of custom headless browsers like PhantomJS, or Selenium/WebDriver for that matter, is dead, IMO. The Chrome DevTools Protocol is the modern standard API to interact with a browser programmatically.
This does sound more promising then, if they've found new ways to add maintainability or QoL aspects to record/replay. As I said elsewhere, I think r/r gets a bad rap, and those sorts of improvements would increase the number of situations where it makes sense (at least for testing in incubation).
I do recommend giving it a try. The web browser automation landscape is much more reliable these days for writing E2E tests than back when Selenium was state of the art.