Making sure that [unit] spawns only on vacant hexes fully prevents 'accidential' overwrites such as https://gna.org/bugs/index.php?14384 , which are annoying bugs and are far more harder to spot than mis-placings and duplications. I would prefer [unit] to work this way, requiring explicit authorization before replacing the unit with another.

However, I agree with 'you are changing the behavior of a WML tag very late in the development cycle.' part and, therefore, propose 'I revert that part now, document, and reapply in 1.9' solution.

yes, silene is right, 'the fact that unit cannot be created in the proper location' is a consequence of my change. but, IMO, it's not a bug, it's a feature - a consequence of the fact that the original unit is still not dead ('A unit isn't erased yet') at this time, so it's square is occupied, so the ghost is spawned at nearest free square.

ai0867, you can go ahead and fix this before 1.8 without worrying about compatibility. wmllint has a test for units speaking in their die events and I have already used it to verify that mainline no longer has any of these cases in it. (I fixed several myself.)

My previous guess was incorrect. The current method of firing events requires that the unit still exists in order for it to be filtered on.

I'll see if this can be changed, but this will almost certainly have to wait for 1.9, so I'm marking this bug postponed for now.

A die event fires after the unit's death animation plays, and the unit disappears. However, in the following code, the unit that triggered the event can be the one who talks. Also, the ghost won't appear in the right place:
[event] name=die [filter] side=2 [/filter] [message] side=2 message= _ "You killed one of us!" [/message] [unit] type=Ghost x=$unit.x y=$unit.y [/unit] [/event]

As a workaround, you can add a [kill] tag to the die event:
[kill] id=$unit.id [/kill] But that isn't obvious, and if it's necessary, it should happen internally.