This is a next step for my project as I'm trying to figure out how to generalize client side predictions in a sane way.

Basically, I'm happy with my latency (for board games) which I hope to migrate closer to people as more edge compute offerings emerge. However, I'm wondering what the path is to find some of these ideas in more latency sensitive applications.

The explanation for how the net-code behind Overwatch is a good explanation: https://www.youtube.com/watch?v=W3aieHjyNvw

and I'm just trying to figure out how to build the reactive tree in a way to support it sanely.

You don't have to predict. Requests just fall into two categories:

1) Nothing bad can happen if we show some optimistic result before server returns, but server side will end up in different result.

2) Something bad can happen. Accordingly, for (1) we can do optimistic update, for (2) can't

Consider that while a videogame runs on 60fps (or more), a board game runs on frame-per-turn. You would be doing what overwatch is doing in a frame, for an entire turn. That's way easier: if a turn is out of sync, revert to the previous one!