+1 for the single scheme (at:// with the /space/ segment). I’ve built this in HappyView, so I’ll try to speak to how it’s working.
First off, HappyView currently supports both formats. I built support for the ats:// based on Dan’s dev diaries, then added at:// after the proposal PR was closed. After building all of this out, I personally lean towards at://.
The /space/ disambiguator has worked well in HappyView: the parser decides space-vs-record on the literal space segment alone, with no network call, no lexicon resolution, and no DB lookup. Dan’s reasoning for it holds up. Being able to tell what’s on the other side of a URI without first resolving a lexicon makes the code a lot simpler.
@bnewbold.net and @ngerakines.me are right that the two read paths barely share any machinery. Public and private records in HappyView are largely separate pipelines. But I don’t think that’s a problem with the scheme. They’re just different sync mechanisms and they were always going to be, regardless of what we call them. What a shared at:// does give us is one namespace and one mental model, which still feels worthwhile to me.
Having built it both ways, spaces do feel like part of atproto regardless of which scheme we use. Same DIDs, same lexicons, same OAuth, same data model… Spaces are just a different sync mechanism behind a permission boundary. I’d rather the scheme say that plainly, and I think the /space/ segment achieves that just fine without a separate scheme.