Windows sometimes does the following if you copy a file into a webdav directory:

• LOCK filename.txt -> 204 No content
• PUT filename.txt with 0 bytes using the lock-token -> 201 Created
• DELETE filename.txt using the lock-token -> 204 No content
• PUT filename.txt with content using NO lock-token -> 423 Locked

Of course this causes an error in Windows.

The RFC 4918 says at 9.6 about the DELETE method:

A server processing a successful DELETE request:
MUST destroy locks rooted on the deleted resource

So windows behavior not using the lock-token at the last step is correct. JsDAV should delete locks on the DELETE method.