- It is really seldom that a patch is reverted (that a patch is removed). As in, it only happens in exceptional cases, when someone has made an obviously toxic patch by accident on on purpose. It's far easier to move forwards with improvements to the patch. We encourage people to do this rather than provide opinions on the code in writing. What this does is interesting: it brings others in the project into the work, and creates instant mentor-mentee hookups. We see this really often and it is a wonderful thing. You make a patch, it's merged, someone sends a patch on your patch and explains why, and suddenly you have someone in the project who knows that area and can teach you.
- Large sweeping changes are sometimes the simplest way to e.g. refactor some code. It's usually a Really Bad Idea to make functional changes at the same time. It also depends a lot on the language. I'd disrecommend large sweeping changes to a C project, absolutely. The risk of introducing multiple bugs is just too high. In a scripted language, far less risk, and so it's safer. In general, functional changes appear to work better as many small testable steps, and refactoring can work as a single mass change.
- OM scales really well. It needs 2+ people in the project. After that, the limits are elsewhere. Projects with hundreds of contributors are probably too large in terms of internal structure. It means you get ad-hoc pseudo-projects inside a single repository which means poor internal contracts, etc. I'd say a project with more than 7-10 active contributors at any time is getting too large. IME a network of small projects works far better than larger monolithic projects.
- I use OM (the C4 protocol) on all projects, whether they are just starting (my first act is then to call for co-maintainers), or have been around for ages (like the libzmq C++ core library, with hundreds of contributors). We've never seen an issue of scale.
Cheers!