@SašoŽivanović So \mmz@pgfsys@getposition isn't linked to \pgfsys@getposition.

@SašoŽivanović I thought that's what \mmzset{deactivate csname=pgfsys@getposition,} would do.

More specifically, I used

\usepackage[extract=python]{memoize}
\mmzset{%
  path={dir=memos},
  auto=\cref{multiref},
  auto=\Cref{multiref},
  auto=\labelcref{multiref},
  auto=\cpageref{multiref},
  auto=\labelcpageref{multiref},
  auto=\namecref{ref},
  auto=\nameCref{ref},
  auto=\namecrefs{ref},
  auto=\nameCrefs{ref},
  auto=\lcnamecrefs{ref},
  auto=\lcnamecrefs{ref},
  auto=\crefrange{refrange},
  auto=\cpagerefrange{refrange},
  auto=\Cpagerefrange{refrange},
  mkdir,
  deactivate csname=pgfsys@getposition,
}

@SašoŽivanović OK. Sorry.

@SašoŽivanović Thanks. & sorry.

@SašoŽivanović :

advice.sty lines 78-9 in the wip version ^^.

I guess it should be

    activate csname/.style={activate/.expand once={\csname##1\endcsname}},
    deactivate csname/.style={deactivate/.expand once={\csname##1\endcsname}},

?

@SašoŽivanović I'm sure this is incredibly stupid, but I thought I would be able to reproduce the issue reliably if I knew the cause. So I tried this:

\documentclass{article}
\usepackage{memoize}
\mmzset{%
  path={dir=memos},
  mkdir,
}
\usepackage{tikz}
\makeindex
\begin{document}
\begin{tikzpicture}[remember picture,overlay]
  \draw [green] circle (50pt);
\end{tikzpicture}%
\begin{tikzpicture}
  \draw [cyan] circle (50pt);
\end{tikzpicture}%
\begin{tikzpicture}
  \draw [blue] circle (50pt);
\end{tikzpicture}%
\begin{tikzpicture}[remember picture,overlay]
  \draw [magenta] circle (50pt);
\end{tikzpicture}%
\end{document}

I thought that If I compiled twice, the cleaned memos/ and compiled again, I should get 3 pictures aborted. (I could then test whatever.)

First run (no aux):

Package memoize Warning: The compilation produced 2 new externs. on input line
674.
grep pgfsys prawf.aux
\pgfsyspdfmark {pgfid1}{9782558}{37309645}
\pgfsyspdfmark {pgfid4}{22942186}{37309645}

Second:

grep pgfsys prawf.aux
\pgfsyspdfmark {pgfid1}{9782558}{37309645}
\pgfsyspdfmark {pgfid2}{9782558}{36523213}

This is all expected, I think. Now rm memos/* and recompile. I expected the first, second and fourth pictures to be aborted and the third to be memoized. Because the second picture will get pgfid2 and memoize will match that against the corresponding line in the .aux file. So it will abort, even though the positioning marker has nothing to do with this picture.

First run (dirty aux):

Package memoize Warning: The compilation produced 2 new externs. on input line
673.
grep pgfsys prawf.aux
\pgfsyspdfmark {pgfid1}{9782558}{37309645}
\pgfsyspdfmark {pgfid4}{22942186}{37309645}

grep -1 pgfsys\@getposition prawf.log
Package advice (/mmz) Info: Activated command "\tikz" on input line 660.
Package advice (/mmz) Info: Activated command "\pgfsys@getposition" on input li
ne 660.

I probably misunderstood your diagnosis.

@cfr Many many thanks for catching this!!!

@SašoŽivanović I figured when you said this, you probably didn't mean I had to edit advice.sty ;). But I can't say I'm convinced by my attempts to test the effect of deactivating, even after correcting the definition.

@cfr You're not alone. I'm testing this at the very moment, and I can't reproduce the problem that hacking \pgfsys@getposition allegedly solved. :-)

@SašoŽivanović You mean pictures with remember picture getting messed up when an earlier picture was memoized and the IDs changed?

@cfr Yeah.

@SašoŽivanović I have an example where I get a different result with memoize than without, but deactivating \pgfsys@getposition doesn't seem to make any difference. (This is with the TL version of memoize.)

The difference disappears with the wip version, again regardless of \pgfsys@getposition being deactivated.

@cfr This is great news! So advancing \pgfpictureid actually does some work.

@cfr And I've got the \pgfsys@getpositionmess almost figured out. I'll report soon.

\documentclass{article}
\usepackage{memoize}
\mmzset{
  deactivate csname/.style={deactivate/.expand once={\csname#1\endcsname}}, % so that it runs on 1.0.0
  deactivate csname=pgfsys@getposition,
}
\usepackage{tikz}
\begin{document}
\section{Foo}
\label{sec:foo}
\begin{tikzpicture}
  \node(blue)[blue,circle,draw]{memoized first};
\end{tikzpicture}%
\begin{tikzpicture}[remember picture]
  \node(green)[green,circle,draw]{remember picture};
\end{tikzpicture}%
\begin{tikzpicture}% [remember picture,overlay] % if this was uncommented, there would be no problem

@cfr Ok, I'll settle for "almost". It seems that the hack was actually solving an inexistent problem. As far as I can reconstruct what was happening two years ago, I managed to erroneously refer to a node not existing in the current picture, but existing in a previous picture (I was developing some complicated styles for dynamic trees in Beamer).

Because the reference was unintentional (the node should have existed in the current picture), the current tree had no remember picture and got memoized. FYI, I attach a some code illustrating the problem — but I'm unable to reconstruct the part of the original where the final result was pretty enough to fool me into thinking that \pgfsys@getposition is doing a real job.

The first picture gets memoized on the first run, when the green picture has ID 2; the third picture does not get memoized because of the undefined reference. On the next run, the first picture is not memoized and the other IDs shift; so the third picture, which now gets memoized, thinks green is in the current picture and performs a wrong shift.

Bottomline: I'm removing the \pgfsys@getposition hack right away. By my tests and your reports, advancing \pgfpictureid appears to do the job, and it's surely also conceptually cleaner.

@SašoŽivanović Interesting. So with memoize I get a different wrong result than without. And I just did something incredibly stupid.