I am not sure the product is really any better. There are a bunch of cute little old things around the printer, they have cool signs and I don't mind the fruit water. There are some other goods things like being able to build a virtual network of devices and things like that, which would be much more problematic without a single provider.
But I would settle for wifi that always works (been working on this in our own little corner of WeWork for a couple of weeks) and coffee that was ready before 9. It would be great if we could just scan our badge at the printer.
I feel like they provide insufficient attention to the basics and really focus on what they think provides differentiation. Maybe in a year I will think differently but if I had to pick a different office space today I don't think I would be any more likely to rent a WeWork given their brand.
If you have many small repos for a large interconnected project you simply move the complexity of managing a commit that requires changes into another tool that can manage cross repo changes and dependencies. With a single repo you can change something and build it, fix any breaks and then commit it with just source source control and build system. The many small repos has in my experience been driven by either poor processes or tooling limitations.
So since it depends on the correctness of the underlying system is there a TLA+ (or other) proof for that? Last time jepsen ran on redis it showed that it was broken unless something has changed in the meantime.
It should always be a prerequisite to have a proof before one begins an implementation. If one cannot construct such a proof then they have no business trying to design new distributed algorithms. Fortunately there are a few algorithms for proofs of replicated state machines available as previously noted.
Proofs will typically show the limitations of an algorithm, for instance the original paxos paper notes that the contained algorithm does not provide liveliness.
A system based on an algorithm with a proof has some chance of being correct, while a system based on an algorithm with no proof while technically it may have a non-zero probability of being correct that probability approaches zero.
Having worked on such systems and having talked to some people who have worked on debugging issues with paxos implementations at extreme scale while it is virtually impossible to to ensure that the system will be able to make forward progress it is possible to ensure that the state of the state machine remains correct.
When I look at an implementation of such an algorithm to evaluate it I pay very careful attention to the test suites. The more bizarre the tests they contain the more likely the implementation is to handle very weird network edge cases.