Ok, I think I really fixed it this time, can you try again?
Sorry..

Another question: if follow(null) can cause problems, wouldn't it be better to remove this synchronous call completely?
Yeah, I'm not really sure what's the best way to handle it yet.
Here's the thing, the follow method just sets the follow target, and then on each game tick it manages its "state machine" to see what's the next move to perform (and if it's stop following, then it will want to stop the existing walk).
So it kind-of follows the same behavior of ChangeRoom in AGS where the script you write after ChangeRoom will actually happen before the room is changed (not a problem in MonoAGS, btw, that's why it's ChangeRoomAsync). And StopFollowingAsync basically calls Follow(null) with an additional task that you can hang onto to wait until the StopWalking happens in the next tick.
Now, I can't really disallow Follow(null) in compile-time yet (
though it will be possible when c# 8 is released). I can make it throw an exception in run-time, though the only problem with Follow(null) is the scenario in which you follow(null) and then walk immediately after it (it might ignore that walk) -> in all other scenarios it will work fine, so I'm not too keen on throwing an exception if you pass null to it.
So here's the possible directions I thought I can take this (let me know what you think):
1. I can make Follow into FollowAsync (and remove StopFollowingAsync) and always return a task, even though it's completely not needed if you don't pass null. And also, it might be confusing for the user, as making it async hints that it will await the entire follow until done following, which is not correct. So I'm not in favor of this approach.
2. I can keep things the way they are for now, and when c# 8 is released to disallow nulls to Follow in compile time.
3. I can change it so it won't stop the current walk when you stop following with Follow(null). I'm not sure what AGS does in that scenario, actually (does anybody know?). But I could just let the character complete its last walk as a follower and then just not do any more walks. And I can make StopFollowingAsync to call Follow(null) and then call StopWalkingAsync, so if you do want to stop walking you'll call StopFollowingAsync and if you don't care you can call Follow(null).
4. I can add an option for StopWalking to accept a specific walking task. Then in the follow component I'll call stop walking on "my" specific walk, so there can't be any confusion, the follow component will never stop a walk issued by somebody else (and I can delete StopFollowingAsync completely). I'm not sure how complicated this is to pull off, but this option might be useful in other future scenarios as well.