Prediction markets are really fascinating. You should also touch on the idea of assassination markets, which I'd say are a subset of prediction markets where the contract price can influence the likelihood of the outcome.
I don't think pair programming is ever *strictly* better than solo programming, but I have found it to be a great way to help teach skills that are hard to describe algorithmically:
Some specific cases:
Debugging: when it comes to debugging, you can read books and watch youtube videos, but you get so much from sitting next to someone who has a good debugging loop.
Performance & Optimization: great to watch how other people do this.
Architecture: this is less about implementation and more thinking through medium-level architecture things. Specifically, picking the right abstractions and patterns.
A non-obvious one:
Overcoming impostor syndrome: I did a Recurse Center batch a few years ago and pair programmed with someone who had >20 years experience, the majority at Google. He wrote half the standard library for a very well-known programming language. So I was pleasantly surprised when I found out that even he reads the docs and sometimes forgets how to do things in that language.
Figuring out what's normal: I couldn't, for the life of me, figure out how to use kubernetes as a friendly part of my development workflow. I pair programmed with someone who was a professional K8s consultant, and asked them about persistent volumes for a postgres instance. I expected a "oh yeah, use this YAML setting" but actually got ¯\_(ツ)_/¯. So it felt good to know that I wasn't the only one who struggles with technology.
Prediction markets are really fascinating. You should also touch on the idea of assassination markets, which I'd say are a subset of prediction markets where the contract price can influence the likelihood of the outcome.