So just to make sure I understand this: This is not about allowing "long" depots, or requiring that players build larger depots to contain bigger train or more trains, but simply letting multiple adjacent depots act as one single depot with multiple entryways?
Does this protect against "teleportation" exploits?

So just to make sure I understand this: This is not about allowing "long" depots, or requiring that players build larger depots to contain bigger train or more trains, but simply letting multiple adjacent depots act as one single depot with multiple entryways?

Yes

Does this protect against "teleportation" exploits?

No, it can be exploited by rearranging train chains. Currently depot size is limited by station_spread setting. So users could "teleport" wagons up to 64 tiles. I will look into it and think about adding a cost for moving vehicles from one tile to the other or moving the whole chain to an appropriate tile for making exploits more difficult.

Are non-contiguous depots prevented?

I like this a lot. Is it a (large) baby step toward #8480, or an alternative proposal?

Are non-contiguous depots prevented?

It should work the same way as building stations do. I (ab)use the same settings used for stations for "station spread" and "allow building distant stations not directly adjacent".
If "Allow to join stations not directly adjacent" is on, you can press Ctrl and join a new depot tile to another close depot. If the same setting is off, no non-contiguous depots can be built directly.

Whether it is necessary to create two new settings or rename the existing ones is something I haven't decided yet.

I like this a lot. Is it a (large) baby step toward #8480, or an alternative proposal?

It is the first part of #8480, but without including extended depots. This is no alternative proposal, but a first step.

I will try and fix the possible exploit and change the current draft state. Anyway, adding another setting for depot spread and setting it to "2" would fix it.

I did a quick test, joining 2 depots of the same type but on different network is not a good idea :). Newly built train is stuck on the northern depot which is on the wrong network. But that's a user error I think.

I have added a setting for controlling depot spread instead of reusing the station spread setting.

About the teleportation exploit, it is very difficult to know in which tile a vehicle ends up after a rearrangement or replacement. Yet it is a possible exploit, it is difficult to apply and to get an advantage of. Anyway, setting a low value for max. depot spread should help with this and I do not want to add extra cost for moving vehicles.

Also, this last year I have had in mind modular airports while working in the "multi-tile depots" and the "extended depot" concept. This month I have finished reviewing how aircraft and hangars are integrated in this PR, so it doesn't make modular airports more difficult to be introduced (at least with my idea of how modular airports should work).

I have finished working on this PR. If it is acceptable to start reviewing it (even with the teleportation exploit not being fixed), I could remove the "Draft" state. Just let me know.

IMO, limiting depot spread is a perfectly valid way of preventing a possible teleportation aspect, since it's similar to how we control station teleportation.

I only got partway through the commits, but will come back later to keep reading. 🙂

For a PR like this, it's unavoidable to have a lot of commits, but in my opinion there are two that could be split off to make reviewing a bit easier:

* [Change: Refactor some code in build_vehicle_gui.](https://github.com/OpenTTD/OpenTTD/pull/9577/commits/d643e77800497b883fdc1b1f58c33d0a874b81fd) can be a separate PR now

* [Feature: Allow vehicle replacements even if new road or rail type is not compatible](https://github.com/OpenTTD/OpenTTD/pull/9577/commits/ced241ed87a26da4d681cbb0727441f5519b3294) can be a separate PR after this is merged.

It will be broken into more PRs than you are suggesting, about 8 or more smaller PRs (the first being about hangars). And I keep this PR for getting a global idea of where I want to go. We talked about it somewhere last year and I think it is the way to go. But I am not going to create all the PRs right now as it would be very difficult to keep track of them.

Once the PR about hangars is reviewed and it is ok (thoroughly reviewed, not necessarily accepted), I will revise some other commits and create another small branch to review.

I think it is better to review and put the efforts on the first commits and then move on.

Anyway, I will correct the things you pointed at here. But as I said, I think it is better to go step by step, amending the mistakes on the shorter PRs, and then move on to the next commits.

I built the PR several days ago and I noticed that when I click on the train button in the extended depot view the game crashed. Sorry I provide a crash dump for that. It's basically this button.

I built the PR several days ago and I noticed that when I click on the train button in the extended depot view the game crashed. Sorry I provide a crash dump for that. It's basically this button.

Thanks. It will be fixed next time I update the PR.