Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2/19/21 11:10 AM, Matt Armstrong wrote:
>>   (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
>>       point where it is already running hooks prompting the user.  Handle
>>       unlock errors there by prompting.
>
> How would unlock-buffer's API change, so that kill-buffer and 
> unlock-buffer's other callers can do the right thing? Would it signal an 
> error, and if so which one (or a new kind of error)?

It turns out that naming a directory the same as the would-be lock file
suffices to induce errors in a portable way.

I've updated the (substantially simplified) test in patch 0001,
incorporating Eli's feedback.

Patch 0002 implements the handling of unlock errors as warnings by way
of a userlock.el function.  I figure that function would be a handy hook
for people to use with `debug-on-entry', if they want.

Both ready for review now.

Things I noticed:

 a) if a buffer becomes unmodified by way of `undo' it is unlocked
    twice, causing two warnings.
 b) the file errors generated contain the original file name, not the
    lock file name.

I am treating both of of those things as not worth fixing, at least for
now.