﻿﻿ MatPlus.Net

Website founded by
Milan Velimirović
in 2006

3:43 UTC
 ISC 2024

Remember me

 CHESS SOLVINGTournamentsRating lists1-Apr-2024
 B P C F

MatPlus.Net Forum Retro/Math A proof game question

Page: [Previous] [Next] 1 2 3

### A proof game question

A) Is a PGx.0 considered to be cooked if a sequence exists in x-1.5?
B) Similarly, is a PGx.5 cooked if a sequence exists in x.0?

Both could be said to be sound if we add the "exact" prefix.
Could it be argued that PGx.0 implies that the position has to be reached with white to play and therefore the cook in x-1.5 is not valid?
Similarly for PGx.5 with black to play.

Maybe this is a "done and dusted" matter. If so, my apologies!

QUOTE
A) Is a PGx.0 considered to be cooked if a sequence exists in x-1.5?

No
QUOTE
B) Similarly, is a PGx.5 cooked if a sequence exists in x.0?

No

Replace 'PG' with 'h#'. Is a h#5 cooked by a solution in 3.5? Of course not, that's called set-play. And non-unique setplay isn't a problem either, as long as no one asks for the set play.
Part of the proofgame stipulation is who has the move. A position with black to move is a different position than the position with white to move.

To confuse a bit: An SPG in 4.5 is definitely cooked in 4.0, because the 4.5 game isn't the shortest. A 'SPG with white to move' isn't cooked by a shorter proofgame with black to move however.

People tend to have strong opinions about minor things, and there are too many quarrels in the world. I present here my own personal perspective.

To me a PG in x.y is not cooked by a shorter PG. Increasingly though I’ve found folk adding “exact” if the diagram can also be achieved in a shorter game, but if the “exact” is missing it’s still sound. However where I differ from Joost is that I don’t think the white vs black to play business is relevant. I.e. if the delta is 1.0, the longer PG is still sound even without the “exact”.

This is a bit different from a helpmate where a short solution with a delta of 1.0 definitely is a cook, while a short solution with a delta of 0.5 is not, because it’s a different starting player. In a helpmate White must have the last move.

This topic was discussed 10 years ago:

https://matplus.net/start.php?px=1663799316&app=forum&act=posts&fid=gen&tid=1139

Andrew makes a very good point, and I share his view (exact is effectively implied in any PG with a stated number of moves).
I would only add that use of the term "exact" in one PG (or in a PG twin) does not surrender the accepted standard (as previously stated here) in another PG by the same author(s).

Even though a proofgame in 3 moves might not be a cook for a proofgame in 4 moves, I'd always add 'exact' to avoid confusion.

Thanks to all for the responses and especially to Geoff for the link to that old thread! I suppose I should have searched before, but it's good to have a fresh perspective!
From the various viewpoints, what I could conclude was:

A) A proof game stipulated with an odd number of moves cannot be cooked in an even number of moves and vice-versa.
B) All proof games are assumed to be also shortest proof games, except when they have the qualifier "exact".
C) The SPG term can still be used for cases where:
----a) The move length is not given
----b) And with a condition like "odd/even number of moves". This is equivalent to stating that W/B made the last move and might be useful to show the helpmate style set play/actual play idea in PGs.

There is no mention of these points in the codex. Maybe it's time they were included?

This dispute was also raised in Wcct.9 also when our PG 8.5 was claimed to be cooked as PG.8. Judges accepted our reply that the side to move is relevant.

Oh Shankar you are a tease: you pretend like everyone is essentially in agreement, and you are summarizing everyone's posts amicably. But in fact consensus does not exist, and you when you "conclude", you ignore half the posts, particularly some more recent ones.

You wrote:
QUOTE
From the various viewpoints, what I could conclude was:
A) A proof game stipulated with an odd number of moves cannot be cooked in an even number of moves and vice-versa.
B) All proof games are assumed to be also shortest proof games, except when they have the qualifier "exact".
C) The SPG term can still be used for cases where:
----a) The move length is not given
----b) And with a condition like "odd/even number of moves". This is equivalent to stating that W/B made the last move and might be useful to show the helpmate style set play/actual play idea in PGs.

Suppose there is a PG in 14.0 which also has a solution in 13.5. Then by your B it is "assumed" to be an SPG, but it is *not* an SPG. There is a shorter PG, but by A this doesn't "cook" the 14.0. What does that even mean?

PGs are different from other genres where it's almost always clear who makes the last move (even in stipulations like h= where logically it would not have to be so). In other genres the creative doubt instead is about who makes the *first* move. PGs are the opposite. White moves first, but there is variability in who makes the last move. However, there is absolutely nothing in the stipulation which implies that the .0 vs .5 business is somehow more important than the 14. or 13. All I know is the diagram is there.

The "exact" was never mandatory, but under your new proposal it is sometimes required, but only when there is shorter solution in e.g. 13.0. We never had to worry about odd/even number of single moves for the "exact" qualifier before. So what do I now conclude about "exact"?

If we go ahead with a Codex change, then here is my initial proposal:
- "PG in x.y" means simply: "find the unique PG in x.y moves"
- "PG in exactly x.y" means: "find the unique PG in x.y moves. Note there is at least one shorter route to the diagram"
- "SPG" means "find the shortest PG"
- "SPG in x.y" means "find the shortest PG, which by the way has x.y moves"
- "SPG WTM" means "find the shortest PG so that White has the move in the diagram"
- "SPG BTM" similarly.

"PG in x.y" is the most common stipulation. In most cases, even those which are C+, there has been no check whether shorter routes to the diagram exist. If you redefine the meaning of this stipulation, then you potentially invalidate all the C+ tags. Keep the generic meaning of "PG in x.y", and then in the future, maybe someone might do a more thorough check over time, and replace the database canonical version of the stipulation with "PG in exactly x.y" or "SPG in x.y". [But the composer's original stipulation should also remain in the database - we have no right to change that or its meaning.]

Love to you all,
Andrew

(1) Under this proposal, Seetharaman's PG in 8.5 also remains sound. He might be advised to get a more precise stip, but the generic stip remains an option without prejudice.

(2) Joost suggests that "PG in x.y" means "find all solutions in x.y". I wondered about that but that means that no problem can ever be cooked by other solutions of the same length, without regard to "intent", which is subjective. Tourneys apply a special context where the solver is asked to find all solutions if they exist of problems of any genre. The Andernach example, I submit, is the exception that proves the rule.

(3) Kostas gives the example of the extra single move. I always try to add this if I can, and in the rare case where it's not possible (e.g. homebase) I would use the "exactly" keyword, which is however kind of meh in a tempo problem. This is not the real question though, which is: are we going to specify that a "PG in x.y" with a shorter solution is unsound?
- Kostas (I think) says "always".
- Shankar says "sometimes".
- I have previously said "no, because we shouldn't trample on free spirits who historically had other interpretations of this stip".

(4) I do see that it would be nice to have a precise meaning for "PG in x.y". Otherwise, the endgame is that all PGs need to be restipulated as either "SPG in x.y", or "PG in exactly x.y". If I change my view, then I would vote for Kostas' "always". This is because Shankar introduces a lot of odd/even single move machinery which only serves the corner case of a delta which is n.0 (and of course n must be an odd number of double moves, so it's even less likely).

(5) Also seriesmovers.

(6) The only point which I feel very strongly about is that if we go ahead with a Codex change, let's draft it properly. No cloudy words like: "... are assumed to be...". List the stip patterns together with the precise meaning of each.

(7) There is then, as Kevin says, a lot of work to be done. He suggests a "grace period" but really when would the work ever be completed? Even Henrik Juel in PDB doesn't look for deltas of 1.0 & 1.5. And that's just one database. We should record the original published stip (we have no right to overwrite that permanently) together with our canonical form.

(8) This was the point of the kinder, loose, albeit ambiguous interpretation of the "generic PG in x.y" that I propose. Look at any dictionary or glossary: many words have multiple senses and that's ok. Left-brain thinking is fine, but it's only thinking with half a brain.

(9) Honestly, I still think this is all a bit of a red herring. I would be much more interested in hearing about progress in understanding "pass" and "tempo", but if there is momentum on this then let's go for it sanely.

QUOTE

- "PG in x.y" means simply: "find the unique PG in x.y moves"

IMO it should be 'find all proofgames in x.y moves', there could be multiple (e.g. in the Andernach solving tourney, the number of solutions is never given, so a PG with 3 solutions would be given as 'PG 14.5' there).

Those interested may read a detailed analysis on exactly this question by the judge of Julia's fairies retro & PG informal tourney 2017-2018, Dirk Borst: https://juliasfairies.com/wp-content/uploads/Award-JF-Retros-and-Proof-Games-2017-2018.pdf (see pages 2 and 3 of the award).

My opinion, as expressed in that discussion, is that in cases like this, the use of "exact" PG is necessary, to avoid confusion. An even better way is to add a move by the other side - this method has been used extensively in the past by many PG composers. See for example the comments in a similar case: https://www.thbrand.de/2014/10/12/retro-der-woche-422014/#comments

Sometimes, playing with a tempo move adds additional content to a PG. Take for example the most famous of these PGs, by Tibor Orban (PG 4.0, not in 3.0 or, 3.5 moves) 1.e4 e6 2.Bb5 Ke7! 3.Bxd7 c6 4.Be8 Kxe8. The shorter solutions are trivial, but the main interest of the problem is to solve in exactly 4.0 moves. It takes some explaining, for the solvers' benefit, to ignore shorter solutions/cooks. This is what adding the word "exact" does.

Here is one of my own PGs in which the word "exact" is necessary (in my view):

Kostas Prentos, StrateGems 2020
(= 14+16 )
PG in exactly 16.5 moves (Duelist) C+

In Duelist chess, when a unit moves, it must continue to play all the moves for its side, until no further legal move is possible. Then, a different unit can move.

Solution: 1.Sh3 f5 2.Sf4 c5 3.Sd5 c4 4.Sc3 a5 5.Sa4 d5 6.Sc5 d4 7.Sd3 b5 8.Sb4 e5 9.Sd5 e4 10.Se3 g5 11.Sg4 Ra6 12.Sh6 Rxh6 13.Sc3 Rh3 14.Sd5 Rf3 15.Sf4 Rxf2 16.Sh3 Rf4 17.Sg1

Try: 1.Sc3 a5 2.Sa4 d5 3.Sc5 d4 4.Sd3 b5 5.Sb4 c5 6.Sd5 c4 7.Sc3 f6 8.Sd5 f5 9.Sf4 e5 10.Sd5 e4 11.Se3 g5 12.Sg4 Ra6 13.Sh6 Rxh6 14.f3 Rh4 15.f4 Rxf4. Any attempt to lose a tempo fails due to Duelist specific reasons. For example: 15...Rg4 16.Rb1?? Rxf4 17.Ra1, but 16.fxg5 is forced.

In this case, adding another move by black (for a PG in 17.0) doesn't work, so I had to use the "exact" tag.

It should be noted that a number of PGs are listed as C+ in various databases, absent specification of the standard used.

The sooner we codify, the sooner we can clarify problems in the databases.
However, there's a flip-side to that coin.
The sooner we codify, the sooner some problems may be considered incorrect (read: codification of a more strict standard will force "corrections" upon problems published under a different standard, despite the fact these problems were never incorrect).

I would humbly suggest that adoption of a more strict standard, absent consideration of this consequence (that it might render previously published problems incorrect), is inherently unfair.
Therefore, we must first adopt the most lenient standard, formally and universally; only then should we consider moving to a more strict standard, thereby explicitly establishing a grace period for all problems retroactively rendered incorrect by a codified alteration of the standard (read: adopt a standard whereby "exact" is presumed for any problem published before the later adoption date, and later determine which problems can drop the word "exact" from their stipulation, without requiring a formal "correction").
This would allow for some auto-correction mechanism, to alter previously published works in the databases, which were correct at publication, without need for an explicit (and unfair) "correction" label.

The sooner we codify these changes, the fewer problems in our databases will require auto-correction.
I would suggest the time-span between standard alteration (if the more strict standard is agreeable) must provide sufficient time to remedy (both to identify and to auto-correct) the vast majority (at least) of problems adversely impacted by this codex modification (I am not prepared to offer a time estimate, nor even to survey the variables involved, but an off-hand guess would suggest a period of years, not months).

Thanks all. I have put some addenda at the end of my earlier post (9) responding to later points.

There is one outstanding issue which has not yet been mentioned -- involving a paradox that has always bothered me...
As a general rule (read: quite naturally), we prefer the most elegant expression (a universal truth -- with very rare exceptions -- valued by all who admire of art).
Paradoxically, the most elegant expression is rarely how a composer should prefer to stipulate a proofgame problem -- our natural inclination to favor the most elegant stipulation is more often a bad idea.

For example, consider the choice between "PG18.5" and "SPG".
The vast majority of problems stipulated as "PG18.5" could be stipulated as "SPG", but they are not (and for good reason).
While the latter expression is certainly sufficient (for correctness), and is clearly the more elegant expression, it's not ideal -- almost always, composers prefer to provide additional information (the number of moves in the intended solution), to reduce the solver's challenge (which may already be substantial).
Taking this into account, it seems to me preferable (paradoxically) to stipulate "SPG18.5" -- meaning: the composer is aware the problem can be more elegantly stipulated (simply "SPG" would suffice), but has provided additional information for the benefit of solvers.

If the standard is going to be rewritten, it seems to me the adoption of this nomenclature might be preferable (whereas "PG18.5" would imply "PG in exactly 18.5").
Doubly paradoxical (there should be a word for that), this nomenclature actually provides the more elegant solution (and may substantially reduce the work necessary to correct the databases).

I think there are three "camps" in this discussion, based on what you believe is IMPLIED in the stipulation PG X.Y. Your view on the soundness of these two sample problems (one repeated from the earlier thread) will show which camp you're on.

Problem 1
PG 2.0
Solution: 1.e3 e6 2.e4 e5.
Is this cooked by 1.e4 e5? Should the stipulation be changed to "PG 2.0 exactly" to make it sound?

Problem 2
PG 1.5
Solution: 1.e3 Sc6 2.e4.
Is this cooked by 1.e4 Sc6? Should the game be adjusted by adding, e.g. an extra move like 2...Se5, to make it a sound PG 2.0?

(A) If you think both problems are sound, you believe that the stipulation PG X.Y implies that the solution must be EXACTLY X.Y moves, no more, no less, so shorter solutions don't count. Hence there's no need to specify "exactly" in the stipulation. Let's call this the "Exact-length Camp".

(B) If you think both problems are unsound, you believe that the stipulation PG X.Y implies that the solution must be the SHORTEST possible, so there are short cooks without the proposed adjustments. This is the "Shortest-length Camp".

(C) If you think P1 is unsound but P2 is sound, you believe that the stipulation PG X.Y implies a certain side is to play in the diagram, so by analogy to set play in helpmates, a shorter sequence by 0.5-move doesn't count as a cook. "Side-to-play Camp".

I'm in the Shortest-length Camp, as this is consistent with all other types of problems. No one will claim that a #2 is sound if a #1 is possible, because the shortest solution is implied in a directmate, and likewise a H#3 solvable as H#2 requires the "exactly" condition to be sound. This is also why directmates, helpmates, series-movers, etc. are not redundantly called "shortest directmates", etc. I view the transition from calling the same problem a "SPG" to "PG" as removing the same kind of redundancy, not as removing the need for shortest play in a PG. Consider tempo play in PGs, which is paradoxical precisely because wasting moves allows you to reach a position in the SHORTEST way. Having both white and black tempo play in a PG is hence not trivial, but look at Problem 1 above. If the Exact-length Camp is right, then 1.e3 e6 2.e4 e5 is sound (without needing to add "exactly") and it shows white and black "tempo play". But what a pointless solution when you could reach the same position with the quicker 1.e4 e5. Special cases like the T. Orban PG 4.0, where an uninteresting 3.0. solution exists, DO require the "exactly" condition.

I actually think the Side-to-play Camp argument is not unreasonable (won't bother to argue why the set play analogy doesn't necessarily work for me). And I certainly don't want the many PGs with 0.5-move shorter solutions to be declared as unsound by any new Codex. It would be unreasonable to force people to modify their PGs for such different views. Incidentally, in correspondence with the late Unto Heinonen many years ago when he was composing those record PGs with the longest tempo-losing treks, I actually persuaded him to change to the Shortest-length Camp. His construction prowess was such that he managed to modify all these complex PGs (adding extra play at the end) to make them undisputedly sound.

There are two groups of proof games: Let's call them shortest proof games (SPG) and exact proof games (non SPG; there is one or more solutions in fewer moves than stipulated). For 99% of PGs, there is no reason for a distinction, because the "exact" PGs are also SPGs. The question arises only when a PG is not SPG. Many composers (myself included) try to make it SPG by adding a single move at the end. If that is not possible, calling those PGs "exact PGs" is the best option, in my opinion. This method avoids all ambiguity for the solvers. More often than not, the argument starts when a solver claims there is a shorter solution (cook), e.g., https://juliasfairies.com/problems/no-1316/ Some problemists consider a shorter solution of this type to be a cook. Some accept such a problem as sound, even when it is not specified as exact. Right now, there is not a universal way to separate the two types of PGs. We need a clear way to separate the two, when there is ambiguity. For my problems, I use "exact". Others don't. Even if it were more or less acceptable that PG in n moves means PG in exactly n moves (it is not, as far as I know), I would still specify an "exact" PG, to avoid confusion.

In most cases, such discrepancies have been resolved already. I doubt you will need to revisit the databases for changes. For the future, I think it is good practice to use "exact" for those PGs that are not SPGs. But this is just my opinion, without any added value, or weight. In the hypothetical scenario that I am the judge and have a problem that is correct only as an exact PG, I will point out the fact (even if the composer makes no such mention) and consider the problem for the award, as sound.

It matters not what composer is in what camp.
We can all agree that a methodology must exist to distinguish:
1) whether a proofgame can be solved in fewer moves (or it must be exactly the number of moves given), and
2) whether a proofgame can be solved in fewer moves with a different player on the move in the diagram.

So, to codify such a standard, only two questions are relevant.

The first question is: looking backwards, what nomenclature provides the best remedy?

My answer is simple: We want not to alter -- in any way! -- the stipulation/diagram/correctness of any previously published problem.
Further, we want not to alter previous versions of the solving tools.
So, whatever camp you are in, "PG2.0" must mean "PG in exactly 2.0" (you must accept the most lenient standard, and the standard which conforms to most of the tools, whether you love it or hate it, if you want to codify a standard which renders no previous works unsound).

The second question is: looking forwards, what nomenclature provides the best remedy (if we wish to distinguish exactness/non-exactness, and whether the player with the move matters)?

Again, my answer is simple... but paradoxical: we should add a letter to the stipulation to distinguish that it could be expressed more elegantly (as a "SPG"), with the number of moves added as a hint.
This is paradoxical, because the general inclination would be to prefer distinguishing exactness (not non-exactness); for reasons expressed below, this paradoxical reversal offers a more beneficial methodology to achieve the same result (distinguishing exact from non-exact, and distinguishing whether it matters who is on the move).

If a composer wishes to distinguish that a proofgame in two moves has no shorter solution (with white on the move in the diagram), they may use "SPG2.0" (busted if there's a solution in 1.0).
A solving tool can effectively ignore the number of moves (or consider that an upper limit -- SPG means solve the SPG).
Similarly, composers may use one additional letter -- say, "ASPG2.0", for any-color shortest proofgame -- to distinguish a proofgame in two moves which has no shorter solution regardless who is on the move in the diagram (busted if there's a solution in 0.5, 1.0, or 1.5).

Full disclosure: I much prefer the suggestion made by Kostas (I can not disagree that his suggestion should have been the standard from the outset), except that adopting that standard today would require changes to previous problems, and changes to solving tools (note: Jacobi reads PG2.0 as "PG in exactly 2.0 moves" -- it does not check PG1.0, it does not check PG0.5 or PG1.5).
Imagine if that standard were adopted today, and a few hundred years later, somebody finds an old problem from 2021 (published or otherwise). They're likely to misread that as cooked, not knowing the standard changed (and publish it with a needed correction). Furthermore, that nomenclature is less elegant than my suggestion, as it requires more space below the diagram (to spell out "PG in exactly 2.0", versus simply "PG2.0").

I am suggesting what I believe offers a better remedy to enable that standard (both looking forward and backward): add a letter signifying non-exactness of a proofgame (rather than several letters to signify "PG in exactly x.y moves"), and add a letter signifying that it matters not which the player is on the move in the diagram.
Thus, when a solver encounters an extra letter (or two), it is significant -- each letter indicates more opportunities to prove the problem unsound.

I believe my suggestion achieves the same result as the standard Kostas suggests, while keeping all problems in the database sound (exactly as they were published), and incurring minimal changes to existing software tools.
Additional letters may be added to older problems, where such changes are verified to be correct.

I don't see the downside (composers are free to add letters to previous works, where possible, and delays in making updates will not impact soundness).
If I am overlooking some significant downside, I would welcome the education.

Do people still use the 'SPG' stipulation?
Recent proofgames seem to all have 'PG' followed followed by the required move count.

For what it's worth I would say that if PG13 is specified and there exists 12 move solutions then the problem is certainly cooked.
Why should proofgamers be exempt from the constraints that all others are subject to?

And of course using the 'exact' qualification is a cop-out in which the composer is admitting that he's aware of the cook.
If only everybody could do that!

QUOTE

And of course using the 'exact' qualification is a cop-out in which the composer is admitting that he's aware of the cook.

It's not a cop-out, but an amazing feat that apparently there's no way to properly lose a tempo.
Would you consider Knud Hannemann's famous #1/exact-#2/#3/#4 AUW also a 'cop-out'?

QUOTE

Why should proofgamers be exempt from the constraints that all others are subject to?

@Neal, as it would be ignorant to suggest other problem forms (e.g., directmates and helpmates) do not already stipulate this term ("exactly"), I must conclude you are arguing that proofgame composers should be similarly constrained to provide a solution which can not be solved in fewer moves, except by explicitly indicating this was intended (by using the term, "exactly", in their stipulation).

So, if that is your point, you make a very fair point here -- proofgames are really just help-games; so, why should the standard not be fully compliant?
And, to further bolster your argument, we must concede that the vast majority of proofgames are composed with the intent that the problem can not be solved in fewer moves.

There is a case to be made that the proofgame standard should conform to the standard of directmates and helpmates.
So, I thank you for educating me on the one disadvantage found in the standard I have suggested: it would make a help-game standard which is considerably different than the help-mate standard.
There's no denying that is a disadvantage (and while I was subconsciously aware of it -- which is why I wish the standard suggested by Kostas was immediately employed -- I failed to explicitly state it as such). Further, to the degree that a help-game and a help-mate should share a unified standard, there is no denying this might be considered a significant disadvantage.
Ultimately, that's the question: can we make a case, given the consequences of imposing this strict standard, that help-games might merit a unique standard (not shared with helpmates)?

If the answer is no, this would constitute the most compelling argument for the standard Kostas has suggested.
I can not disagree that such a standard should be considered ideal (it is a great pity that strict standard was not immediately adopted).
However, adoption of that standard today will have significant consequences which must be considered -- by codifying this more strict standard, we will render unsound many problems published under the more lenient interpretation and we will incur significant work (to renovate databases and solving tools, which will be similarly rendered incorrect).
So, those are the tradeoffs we must consider...

If we are going to change to the ideal standard (which is what Kostas suggests), I renew my petition for a grace period.
By gradually transitioning into the new standard (while encouraging conformity for all new problems), we will have time to renovate solving tools and databases.

QUOTE

And of course using the 'exact' qualification is a cop-out in which the composer is admitting that he's aware of the cook.
If only everybody could do that!

The second sentence was already addressed (everybody is free to stipulate an exact number of moves -- this has been done in directmates and helpmates).
The central question remains: what nomenclature do we prefer to make this distinction?

The first sentence is ignorant of the value of problems which use the term "exactly" in the stipulation (try composing one, and you might begin to appreciate their value).
As Joost notes, such compositions can hardly be considered a "cop out."

Here's a problem everybody should know:

Tibor Orbán
Commendation
Die Schwalbe, 1976
(= 15+15 )

PG4.0 {C+}

Note: This is how the problem appears in Win Chloe (the term "exact" does not appear in the stipulation), and the problem is listed as C+ there. On PDB, the stipulation reads: "BP in genau 4,0" (translation "PG in exactly 4.0 moves"). I am uncertain how it was stipulated in the original issue.

The above problem is arguably the most popular proofgame of all time (most players with zero interest in problem chess will have attempted/solved this one). This was one of the first proofgames I attempted to solve, and I can still recall my amazement in seeing the solution (I honestly can't recall whether I solved it, but I doubt it -- I had little patience when I was just beginning to appreciate such problems).

It is certain the author was well aware this problem has four solutions in 3.5 moves (none of which are interesting), and four solutions in 3.0 moves (ditto); but, this unique solution in 4.0 moves is truly remarkable (once you've seen/solved this problem, you can never forget the undeniable value of this discovery).

It would be beyond ignorant to suggest that this composition -- which stands as the most elegant expression of this paradox (losing a ply or two can be a real challenge for the solver)! -- is in any way a "cop out"; quite the contrary, such problems typically involve remarkable ingenuity (and they create some of the most pleasurable experiences for solvers).

note:
If you enter the following input into Jacobi, for the PG4.0 above, you obtain a single (unique) solution.
stipulation PG4.0
forsyth rsbqkbsr/pp3ppp/2p1p3/8/4P3/8/PPPP1PPP/RSBQK1SR

Jacobi does not produce the four solutions in 3.5 moves, nor does it produce the four solutions in 3.0 moves. Thus, Jacobi agrees with Win Chloe.
Thus, we can hardly argue the more lenient standard is an aberration (it is, in fact, widely accepted).

That is why I argue that the "PG4.0" stipulation should not be codified in a manner which renders a previous work unsound (nor database entries unsound, nor solving tools incorrect).
I have suggested what I consider a better nomenclature (if we want to codify a standard which distinguishes proofgames based on shorter solutions and/or proofgames which have shorter solutions but leave an alternative player on the move).
To the extent possible, we should prefer to leave unaltered all previous works, databases, and all previous solving tool versions. Further, we should prefer a nomenclature which takes less space below the diagram. Finally, we should prefer a standard which provides solvers some alert that the problem allows for greater cook opportunities.

I fully accept that the standard suggested by Kostas should have been codified from the outset (going way back to 1976, if not before), but I have argued this is no longer the ideal nomenclature today.
There is one significant disadvantage of my suggestion (the nomenclature would be different for proofgames, versus helmpates and directmates), but I would argue the transition to the ideal standard has more adverse consequences.

I would further argue that a help-game is inherently quite different from a help-mate (thus the standards need not conform).
Evidence: "PG" is NOT to "h#" as "SPG" (shortest proofgame) is to "SH#" (series helpmate).
If conformity of standards (between help-games and help-mates) were a legitimate goal, the codex would need to address this divergence.

I will accept whatever standards the problem community decides upon, of course, but I strongly encourage a careful consideration of what standard/nomenclature is most beneficial (and agreeable to proofgame enthusiasts). We do need to formally codify a standard (whatever standard wins the day).

In spite of the disadvantage, I would advocate for a unique proofgame standard which:
1) distinguishes whether the composer accepts that they are cooked if the diagram can be achieved in fewer moves,
2) distinguishes whether the composer accepts that they are cooked if the diagram can be achieved in fewer moves regardless which player is on the move in the diagram,
3) alerts solvers when there are greater cook opportunities (from the two points above),
4) provides an elegant nomenclature (using little space below the diagram),
5) does not render unsound any previous work (or minimizes that impact) which has been previously published,
6) minimizes the updates necessary in databases, and
7) minimizes the impact upon solving tools.

The first two points are critical.
We must provide a standard which allows for cooks in fewer moves, because the vast majority of proofgames are composed with this in mind (read: they were never intended to imply "exactly n moves" in their stipulation).
I maintain that solving/cooking options are essential information (which must be provided to solvers), and I see no disadvantage in a stipulation formally distinguishing those problems which have a solution in fewer moves (read: the possibility that a shorter solution might exist is hardly something a composer would prefer was concealed from the solver).

I am almost certain all of my published proofgames have conformed to the standard Kostas has suggested, and I must affirm that it is incorrect to view all proofgames (including those which were never intended to imply an exact number of moves is required) from the perspective of the more lenient standard. If a new standard does not formally distinguish (and codify) this intent correctly, I am forced to seek an alternative form of stipulation (which correctly conveys what the problem is intended to show). Thus, there is no good case for codifying the lenient standard (and applying it to the vast majority of problems, which were intended to meet a higher standard).