1. Even though I have a lot of experience with LTN, the last time I couldn't get it to work. It kept saying that there was no resource in the network for delivery. I couldn't figure out what was going on for a long time. I decided that LTN wasn't working on the 2.0 version of the game. But then I realized that maybe it was the network number. And indeed, for some reason the default network became 0 instead of 0xffff. This change made LTN even more difficult for newbies. And old blueprints don't work correctly now.

2. Then I started noticing that when there weren't enough trains in the network for delivery, sometimes the trains would deliver more than was requested. I couldn't figure out what was going on for a long time. I've never had this problem before. It turns out that the "Requesters ignore stopped trains" setting affected it. I disabled it, and the problem disappeared. It would be better if this setting was disabled by default.

I couldn't agree more with point #2. Why this setting is on by default is beyond me. There's report on the Gitgub for this exact same issue because with it set, people think LTN is bugged out. Also, the timeout should be ZERO by default. Not being set to zero, trains go back to the depot with material still loaded. If this happens, now you have a base with contamination EVERYWHERE. So, a simple flipped pump for unload or mini loaders flipped can bork your entire base forcing you to go back to a previous autosave.

see https://github.com/hgschmie/factorio-LogisticTrainNetwork/blob/master/changelog.txt#L48-L53

Basically, ask yourself what is worse: Checking the defaults once if 0x0 does not work for you or get burned constantly if you flip the output switch of your combinator to "off", the combinator stops sending a network signal into an LTN stop and it falls back to the default which is "any network welcome at this stop".

The defaults are documented in the README (https://github.com/hgschmie/factorio-LogisticTrainNetwork/blob/master/SETTINGS.md#changed-in-220-default-network-id-ltn-stop-default-network---integer-default-is-0), I wrote quite a bit of documentation for 2.0 (the lack of good docs was IMHO always a problem with the 1.1 version).

The response to 2) is more nuanced (and probably needs some additional documentation):

• If you have requester that can unload a train slow, so that there is a significant amount of cargo still on the train when the next one is dispatched to your stop, then you should unset the "ignore trains stopped" setting. Otherwise what is happening is exactly what you describe. E.g. if there is a request for 40 stacks of iron and the station has only unloaded one stack from the train when the next train is to be dispatched, you will receive a second train with 39 stacks.
• If you have a requester that is really fast (e.g. I have stations that use twelve miniloaders per cargo wagon to unload a wagon in one or two seconds) and have high throughput, you want to turn the setting off to receive full trains all the time.

Admittedly, the defaults are geared towards the latter (high performance mid-end game stations), it is worth rethinking the defaults. Please file an issue on github so I won't forget to address it.