You can witness this even in leisure activities. Some people want to plan ahead which museum to visit or when to have dinner, others don't see the point. Either approach works as long as people get along.

You just described my wife and me - and the getting along part is the tricky part ;) Coding-wise I swing between both ends, depending on task on environment, but in either case I try to keep Eisenhower's wisdom in mind: "plans are useless, but planning is indispensable".

I thought the clients and server can (and should) co-evolve constantly.

I fail to understand how, without having some upfront spec. If we want to minimize upfront planning and white-papers, we need something to code against, so we could simple let the server-side code talk and the client-side follow. Setting up the server and implementing 3 APIs should be a short enough lead to not thwart the overall development process significantly.

As you can tell, I've been so impressed by GraphQL that I'm skeptical there could be a better alternative, but I'll gladly look at any other suggestions.

We already discussed that before and I mentioned my pros and cons; in summary for me it's something like a 48:52 decision, so I'm fine with whatever we decide to do.

If we choose GraphQL, it solves this problem handily because the API response format is completely client-dictated.

That's again not fitting squarely into my brain ;) If we just imagine two Scheme clients and an Emacs client, I think that they can share so much more than just what they expect from the server - and I would hope that we would greatly improve the quality of the client implementations by sharing common best practices and ideas as they come up during development. If so, that sharing can be heavily simplified by not starting from completely opposite ends. Admittedly the tricky part in this case is to find the right balance between alignment and creative flow of thoughts, but this anyway our daily business.