I believe Artem only wanted to make sure it is a durable approach, with few future changes

How about a simple array of damage objects?

room.damage = [{dealingPlayer, dealingCreepId, takingPlayer, takingObjectId, damageAmount}]

I understand your concerns regarding a temporary API. But it also wouldn't need to be 100% perfect. I think something like the above would be suitable for most szenarios.

If "my" script can't handle a leaving hostile creep (into an other room out of my sight), it shouldn't be your fault, right? At least it wasn't before this topic. If that damage dealing creep is dead already, why should I care about it, but I still know the player.

The above approach could also simply be extended with further metadata about the attacker, like dealingCreepPos, if that is required, or any other future requirement. Or you can make it even more generic using dealingObjectId and dealingObjectType instead of dealingCreepId, to support nuke or power bank damage...

I don't care about the change. 
But I wanted to note, that the old documentation indeed contained mode values as well. 
There is a cached version of that page here. Well, it's not loking the same anymore, I guess it's lacking some stylesheets... 

Whatever. Keep up the good work

I think it is important to mention that this is a game for developers (or aspiring ones). Offering such an API, it must be assumed to be used. And finally this means it becomes/is (an advanced) part of the game.
This would mean there is no such thing like abusive use, except when using exploits or the like.

But I’m unsure as well if this is what game developers had in mind when creating the API or if its consequences could be foreseen. It can give very powerful advantages.
So I am with W4rl0ck – maybe we need a discussion about what should and what should not be possible to do with the API in terms of what it offers. What may be too powerful at all. What needs sensitive limitation. Some things may be missing as well. 
But I wouldn’t call using powerful implementations of given functions abusive, as it has that “illegal” touch. I’d consider it more like Atavus calls it “unfair”.

And in no way should the usage of given functions result in something like "banning" (well, again except regarding exploits, explicit abuse...)

It could also be an option to introduce another currency, to be used for API calls to limit its use. This offers a lot of more options, regarding its implementation, e.g. when and how it increases/reloads or how API call costs are calculated.

Like it could refill faster by killing other creeps ^^
Just an idea… I guess there are a lot of possibilities.

I'm not interested in arguing about this interpretation, only want to note that OCS officially exists since Sept. 10th 2016, founded on github, not the date mentioned above. 
But never mind...

Well, `memCreeps[deadCreep] != Game.creeps[deadCreep]`. 

Are you storing a property .name in your creep's memory? If not, then `memCreeps[deadCreep].name === undefined`. 

Unsure about your spawn. You may want to log homeSpawnID as well...

How do you get better error messages then? 

You can't. Or well, you may try an other browser.

But what really can improve your bug fixing experience is to use the debugger. Most current browsers offer a debugging tool, commonly you can open it hitting F12 or have a look in the options. 

You can also set "break points" by writing  
 debugger;  
within your code.
The browser's debugger will halt at that location and you can step through your code. 

There are some novice areas around... Are you waiting for a respawn area to appear in a certain area? 
If not, whats wrong with the novice areas? 

I guess respawn areas will only appear under restricted cicumstances...

There are some “common” cases which may lead to strange movement behavior.

• If you are using a different target pos for moving into the room and are calculating a new path as soon as you enter the room, the new path may be a route through the room where you actually came from (entering through an other entrance). As soon as the creep is leaving again, your other code part may calculate a simple path into the room again (e.g. to pos 25/25), and the procedure repeats.
  
  Setting maxRooms = 1 for path calculation after entering the target room, will force to take a path through that room only. It’s a quick solution for the problem. While it may still be an issue in “certain” scenarios, where you have to take another path into the room at all…

• There may be some scenarios, where path calculation becomes expensive (cpu operations). There is a maxOps parameter, preventing to exceed a threshold (default:2000 (~2cpu)). You will not get a valid path if that threshold is reached.
  
  Increasing that threshold can solve the problem, but may lead to cpu issues if you are not caching paths. But I guess this one is more relevant for inter-room paths…

Oh yeah, please merge!