> Obviously conflating the two variables into one is a change visible to
 > the user.  I'm just saying that it would fix your bug as well.

It's not my bug.  Which means, I don't have a user perspective here and
everything I say is purely speculative in this regard.

 > And I think it's a choice that might make a lot of sense.

Maybe. Just that people have to be aware that any character they insert
after rear-sticky invisible text will become invisible too.

 >>Because I'm not allowed to disable point-adjustment for the normal
 >>`line-move-ignore-invisible' t case.
 >
 >
 > AFAICT the reason is not that you're not allowed but that you haven't
 > needed to do it.  If you needed to do it, I don't think it'd be a big
 > problem since line-move already tries to avoid invisible text (so
 > point-adjustment shouldn't make much difference if any).

`line-move-ignore-invisible' is about _invisibility_ only.  Adjusting
point is about invisibility, composition, intangibility, fields ...
Now, if I set `line-move-ignore-invisible' to nil I might want to stop
at the next invisible newline but still respect the remaining
properties.  I understand that's what "conflating" is all about and I
agree that there's no peculiar reason why we should just consider
invisibility and not the rest.  Moreover `line-move-ignore-invisible'
seems broken anyway and hard to get right.

 > So I now think that setting disable-point-adjustment only in the
 > interactive case is actually incorrect: it should also be set in the
 > non-interactive case.

Currently point-adjustment affects point-setting only _after_ a command
is executed.  `line-move-ignore-invisible' affects point-setting for
every single line move, regardless of whether this happens in a command
or how often this happens in a command.

Anyway.  Is the attached patch about what you have in mind?