[PATCH] Bug: fragile org refile cache

[Maxim Nikulin]

Reviewing my attempt to speedup collecting of refile targets
https://orgmode.org/list/s209r8$16en$1@ciao.gmane.io/
I have realized that refile cache is unreliable.

With specific customization, cache content and thus refile targets 
depend on the function called first: `org-refile' ([C-u] C-c C-w) or 
`org-goto' (C-u C-c C-w).

I decided to try to provide minimal example and steps to reproduce in 
the form of a test marked as expected failure.

Certainly cache should be enabled
    (org-refile-use-cache t)
`org-refile-targets' should have (nil . (:maxlevel . 5)) for the 
affected buffer. The value of the following setting is intentionally set 
to alternative value in comparison to `org-goto' code
    (org-refile-use-outline-path nil)
To see the issue interactively, you likely should set
    (org-outline-path-complete-in-steps nil)

Clean cache (C-u C-u C-u C-c C-w) and try jumping using C-u C-c C-w and 
C-u C-c C-j in various order. Use TAB completion to see targets.

To make difference more apparent, define 
`org-refile-target-verify-function' to filter-out some headings.

My expectation that each command has list of targets formatted 
accordingly to user setting or `org-goto' internal overrides. Actually 
lists of target are the same since they share cache entry.

I suppose, cache keys should include values of all parameters affecting 
filtering and formatting, not only regexp for heading selection.

However I have no idea how to derive some value suitable for cache key 
from `org-refile-target-verify-function'.

0001-testing-lisp-test-org.el-Refile-cache-failure.patch
Description: Text Data