MAR - you're still missing the main points.
Are you suggesting that doing a stalemate check is harder than solving a position?
Your Blathy example is of something not applying to my suggestion.
...
Seems like I am.
Answer to first is "no", but I see no relevance.
As I understood it Bláthy example was exactly applying. You'd better explain it again, because I think @Elroch understood it the same way.
Added further to my previous reply posts just now. By editing.
Your Blathy position doesn't have 'won position' elements.
Where/what is the won position in it that was 'added to'?
Not an explanation but rather 'resistance'.
---------------------
Idea: Start with positions that Syzygy has already solved and classified as wins.
Add material to the winning side.
But do a stalemate check. That's the 'algorithm'.
Not just if its stalemate - just make sure that the winning side can avoid stalemateing.
Which isn't a deep thing.
Note that it wouldn't be considering positions already stalemate - anyway.
Because its only considering positions that are already wins.
It just has to make sure that if and when its on move that it can avoid stalemating.
And things like perpetual check - with either side to move.
Pretty hard for the losing side to check - with Lone King.
------------------
I was mildly surprised when Grok indicated there was nothing published on this.
But Grok agreed with me that many would have thought of it already.
-----------------------------
Martin - if you want the Python script for this - and the API calls for asynchronous rollbacks and also the stack pointer considerations ... then maybe that could be a wait.
No full Monty breakfast nor Monty Python script available.
MAR - you're still missing the main points.
Are you suggesting that doing a stalemate check is harder than solving a position?
Your Blathy example is of something not applying to my suggestion.
...
Seems like I am.
Answer to first is "no", but I see no relevance.
As I understood it Bláthy example was exactly applying. You'd better explain it again, because I think @Elroch understood it the same way.