I feel that connections will be just as complicated... especially for players.
Well, it would make for a much deeper simulation, and it would introduce something sorely lacking (IMO) - competition between players. The competition is very limited, as is. Ok, there may be more than one player starting from the same base, as you, but eventually (with exception of slot limited airports), one player will become dominant, and from that point on, we are pretty much playing solitaire.
The bases added some competition, but with the 70 plane limit, you can't really challenge a larger player at his home turf. You can challenge a smaller player at a second tier city, and that's about it.
The current demand system is based on existing hubs. Meaning that if a guy is flying from Buffalo, NY to, LHR via JFK, he is built into the LAX LHR demand. If there is a dominant player at LHR (and of course there are no slots), and a dominant player at JFK, no-one can compete for this passenger, and the demand is misplaced anyway, because it is represented as JFK-LHR demand, rather than BUF-LHR demand.
With the connection feature, anybody (or their team-mate) who happens to fly to BUF and LHR can compete for this passenger's business, not just JFK and LHR incumbents. So there would be a lot of indirect competition.
Anyway, city based demand opens up many more possibilities in the game, especially when it comes to allowing people greater choices in basing.
I guess there may be many interpretations of what a city based demand really is. It can be:
1. just a way to figure out inherent airport (demand originating from airport's surrounding ares, not from connecting flights). This would be my preference to get things off the ground quicker. Under this scenario, each airport would be allocated some demand based on the population surrounding the airport. For example, JFK would get some allocated, as well as LGA and EWR. The ratio would stay constant throughout the game. All the action would be in building connecting flights.
2. City would have a certain demand, and airports serving the same city can steal traffic from each other from overlapping areas. Demand would really be tracked not on airport to airport bases (2755 of them) but on the land squares, some 40,000 of them, and even those square were too big according to some. So multiply 40,000 x 4 if you want each square to really be divided into 4 sub-squares.
And what does it buy for us? Not a whole lot, because of the 6,000 pax demand between JFK and LHR (in current ATB), maybe 2,000 live withing the squares of JFK and LHR, and the remaining 4000 are transferring from places such as Buffalo, New York, Scranton Pennsylvania, Glasgow, Scottland.
IMO, multiple airports with overlapping coverage is just an ugliness of the real world that threatens to bog down the beauty of the simulation that Sami is building, with little to no improvements to playability.
As far as flexibility in player basing, we are talking about a handful of cities with these "issues" needing flexibility. But the LHR problem would be greatly diminished. If you take current AWS demand allocated to LHR, in the new version of demand (whatever it turns out to be) LHR demand will be cut down to probably no more than 25% of its current demand. The demand will be distributed throughout the other UK and continental airports that LHR is serving (connecting). And suddenly, LHR slot problem disappears. It is no longer crucial to be based at LHR, to have slots at LHR, since the action is in the connecting flights, and the hub connecting these flights can be anywhere.