How exactly is op perfectly interleaving stdout, stderr?

I'm hoping one of the `op` developers sees this as I've been wracking my brain over how exactly the CLI is seemingly perfectly interleaving writes to stdout and stderr? I work on the Azure SDK for Rust currently and to test our Key Vault library I wrote a CLI that reads secrets from Key Vault inspired by `op`, which I use a lot. It was just a fun little side project, but it's quickly turned into a bit of a white whale.

I've a lot of experience writing terminal apps (going back to HP-UX) and created a couple pipes to redirect stdout and stderr before forking the child process. The problem is that you have to poll the reader end of the pipe. I spawned a couple threads to monitor each and while it's quick, it's not perfect. I have a sample app that writes to stdout and stderr back and forth in rapid succession. `op` does it perfectly - and maintains VT100 sequences - while mine tends to write a few of one stream, then another but, because the reader end of the pipes aren't TTY, without color. I could create PTYs (pseudo-terminals) to solve that, but still have the same problem above. If I create a single PTY it solves the TTY issue but not I can't differentiate between stdout and stderr. I've spent a significant amount of time reading others' solutions but everyone has the same problems. I know you still differentiate because I can redirect either stream

I know `op` is written in Go (`op` version 2.30.3 was built with Go 1.22.7) and I was looking at their `os.Pipe()` implementation but it's not really any different than Rust's `std::pipe::pipe()`. I've written quite a few term apps in Go as well and have always had the same problem.

So if any `op` devs do see this and are willing, I'd really love to know how you pulled off seemingly perfectly interleaved and colored piped writes to stdout and stderr.