bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code

[Max Nikulin]

Stefan, my apologizes that I sent first copy exclusively to you.

On 06/05/2023 01:17, Stefan Monnier wrote:
> > I have no ideas how to make `org-assert-version' better.
>
> `my-require-with-shadow-check' is a suggestion to make it better.

My current opinion is that `my-require-with-shadow-check' may be an 
improvement when *combined* with original `org-assert-version' (that 
inscribes org-version into .elc files).

The reason why `my-require-with-shadow-check' may be significantly less 
efficient if it will *replace* original implementation of 
`org-assert-version' is the following.

Consider a user who cloned org-mode git repository and loads Org mode 
from there with periodic pull and rebuild actions. Forget about built-in 
Org and assume that `load-path' is modified early enough to not cause 
any problem.

Now literally citing my Fri, 5 May 2023 11:18:17 +0700 message
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#140

Does in help in the following case?
1. Base Org part is loaded on opening of some .org file.
2. Org in that directory is updated and recompiled.
3. New Org feature is loaded (autoloaded or by explicit call of e.g.
   (require ob-shell))

Additional argument:

When the reporter got the error from `org-assert-version' it was not 
necessary a false positive (however most probable on minor version 
update), user may face an error later while running Org because not all 
files were recompiled after changes in macros.

I am in doubts if `my-require-with-shadow-check' may help in such cases.

> And this sub-thread of the bug report was presumably your answer to the
> question by Ihor:
>
>      Max, do you see any obvious downsides in Stefan's idea about consulting
>      `load-history' vs. `load-path'?

My excuses:
- message subject has not changed, so it was unclear that it was decided 
to discuss purely mitigation of symptoms instead of fixing of real cause
- participants of discussion are spread across time zones, so a longer 
messages may be preferred
- Configuration of https://debbugs.gnu.org is worse than 
https://bugs.debian.org, reply to specific messages links are missed.
- debbugs and thunderbird are not friends in respect to mbox links (and 
I have not created a wrapper script that should work as a workaround)