And in case anyone's interested- this is not something that happens in the 'old' smoke sim-

Loaded the Mantaflow file into Vanilla Blender (2.81a release version), and added the 'old' smoke sim to all items, only change made was lowering the domain vorticity down to 0.
It works as expected / correctly. Here's the 'old smoke' file-

Also of interest is the fact that it bakes over 3 times slower, for arguably the same simulation, in Mantaflow, compared to the 'old' smoke sim-

This was using the two previously uploaded .blend files for comparison. On the same machine, with the screen capture software running, so an 'even playing field' situation.
I don't know if you'd call this a separate bug, or even a bug at all, but it's certainly not an improvement over the old system, from a usability perspective.

Regarding Blender crashing when the collision outside the domain is enabled, I was making another scene to test the above issue, and this scene basically crashes Blender as soon as you attempt to bake with a second effector / collision object enabled.

Try to bake without the 'CylinderCollision' object enabled, then try again with it enabled- I tried it on 3 different machines and Blender crashes as soon as you press 'bake' on all of them, so it looks fairly repeatable.

Seems I cannot reproduce crashes (tried buildbot builds rBda6929488a64, rBc2a37867f21b).
Tried AdaptiveCollisions.blend and SmokeCollision_Mantaflow.blend

System Information
Operating system: Linux-5.3.12-200.fc30.x86_64-x86_64-with-fedora-30-Thirty 64 Bits
Graphics card: GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.31

This might be a Windows-only issue?

When you say you can't reproduce the crashes, do you mean that the 'SmokeCollisions_Mantaflow' file works properly when you bake it with Adaptive Domain enabled on Linux, with the I'm guessing more recent builds, or the Domain keeps bouncing off the collision object like I get (first video), so you do see the bug?
This is the actual bug I'm reporting, the crashing is just a bonus feature really.

Could be a windows thing- I'm Windows 10 only machine wise, and I'm only using rBed32db06c124 (16-12-2019 build) for testing this bug, as it's the build I found the bug in (the one on blender.org in the 'experimental builds' download area as of 10 minutes ago), I never use daily builds, only the download from blender.org.
Mantaflow gets rebuilt quite/very often, so I'd say it's pointless testing with later builds unless it's to compare them to the build used which shows the bug, as in try the .blend in exactly the same build & OS first.

I just tried it on a third machine (HP Z800, and it crashes as soon as you attempt to bake with the cylinder enabled.
All 3 get the same results baking wise (SmokeCollisions_Mantaflow.blend), as in the domain won't expand past the collision object to it's full dimansions when adaptive domain is enabled.

So that's:
an AMD Threadripper 16 core workstation (self-built, 64G Ram, gtx 1070ti + 1070),
a dual 6 core Xeon (HP Z800, 72G Ram, 1 x GTX 1070), both running windows 10 pro,
and an i7 Laptop (Gigabyte Aero15 i7-8750H, 16G Ram, 1 x GTX 1060) running windows 10 home. All using the 16-12-2019 Windows build.

All crash as soon as you press 'bake' with the cylinder enabled using the 16-12-19 build.

Hello again

Stupidly (apparently) I've been using the Mantaflow version from the experimental builds page, this would appear to be out of date (and should be removed from the page- see my rant in my last comment on this bug T73078)

I've just tried this in 2.82Beta and 2.83Alpha and the bug is completely gone (and the instant crashes), please close this bug!

Sorry for wasting anyone's time, and please, please lose the download from the 'Experimental Branches' page- it's well out of date and confusing as Mantaflow is no longer 'Experimental' and should only be tested / used with 2.82BGeta or 2.83Alpha.

Cheers!
Mark