>> In my previous patch there is no need to check for the buffer,
>> because a new general variable is declared as buffer-local.
>
> But the BUFFER argument of 'window--display-buffer' is not necessarily
> the current buffer.  Or do I miss something?

Thanks for pointing out, fixed in a new patch.

>>> What happens with these markers when 'display-buffer-no-window' gets
>>> called?  Or some user provided routine provokes an unhandled error?
>>> You don't even check the marker buffer of these variables so some old,
>>> completely unrelated marker could get reused here.
>>
>> There is no global effect because this feature is localized
>> to a single buffer by its buffer-local scope.
>
> We would always have to assure that the marker's buffer and the
> current buffer are the same.  And we would have to make sure the
> marker gets reset when an unhandled error occurs.

Assured in a new patch.

>> We could support an action alist too in addition to buffer-local variables,
>> but we should leave an ability to set buffer-local variables, because
>> neither view-lossage nor vc-git-print-log (two primary cases to test
>> this feature) have no access to the 'action' arg of display-buffer.
>
> Maybe we could provide a new macro which encapsulates the use of these
> variables in a more disciplied fashion (providing the necessary action
> arguments for `display-buffer').

Frankly speaking, macros like with-help-window, with-temp-buffer-window
are terribly ugly and look like a kludge.  For example, after applying
the following patch, all source files that use the changed macro,
need to be recompiled, so everyone will need to do bootstrap after
pushing it, and many other problems.  I see no reason to use macros here.
We need to replace these macros with the elegant solution that we already
have of using action alists.