Loss when it should be a draw?

"If they can force mate" isn't used for other positions, for example had White flagged you certainly wouldn't rule this a draw.

Valid point.

@Duubik regardless... if the possibility of helpmate exists. you will lose the game if you lose on time.

Where are the borders between

-one extreme unlikely helpmate
-helpmate possible
-accidental mate posssible
-minor piece and king trapped in corner
-close to corner, 1,2 squares away
...

What's all the fuss about it? Everyone agrees if a pawn remains and there's not mate lightyears ahead.

I am happy that there are clear, simple rules.

Intuition matters.

Rules are social constructs. There is no abstract principle existing independently of society that can overwrite the intuition of a society that creates rules for its own working.

If we start being strict and adhere to abstract rules that are counter intuitive then we can begin exporting annotated PGNs where annotations are, get this:

A DOLLAR SIGN FOLLOWED BY A NUMBER

Yes, this is how a correct annotation looks like in an exported PGN. This is what the standard says. I have seen no exported PGN in my life that implements this rule. Neither does lichess. Lichess annotates moves in exported PGNs with suffixes !, ? etc. as intuition and common sense dictates, not how abstract and counter intuitive rules dictate.

Source:

www.chessclub.com/user/help/PGN-spec

8.2.3.8: SAN move suffix annotations

When exported, a move suffix annotation is translated into the corresponding Numeric Annotation Glyph as described in a later section of this document. For example, if the single move symbol "Qxa8?" appears in an import format PGN movetext, it would be replaced with the two adjacent symbols "Qxa8 $2".

If you think PGN is supposed to be intuitive, you haven't seen what Fritz and other software do.

I created a study. It has only one chapter and this chapter has only one move 1. e4, which I annotated "!" using the study's built in annotation feature.

Then I exported the chapter PGN, using the study's export function.

This is what I got:
__________________

[Event "sakkozik's Study: Chapter 1"]
[Site "lichess.org/study/pe8AtguR"]
[Date "2017.05.12"]
[Variant "Standard"]
[ECO "B00"]
[Opening "King's Pawn"]
[Annotator "@sakkozik"]

1. e4!
__________________

This is not an exported PGN. This is exported INTUITIVE GARBAGE, because it annotated the move 1. e4 with an exclam instead of a $ and a number, as it should have according to the official PGN specification.

So the menu really should say "Export INTUITIVE GARBAGE THAT IS NEVERTHELESS USEFUL" rather than "Export PGN".

You're conflating two concepts:
* Whether a specification is supposed to be intuitive -- this would need to be taken up with the specification committee
* Whether "export PGN" is objectionable on the grounds that it exports a file which does not fully conform to the specification -- it really isn't

Surely many (but not all) programs which can import PGN are also capable of importing non-PGN files containing characters !, ?, and similar (many of which are unicode glyphs rather than ASCII characters).

"Surely many (but not all) programs which can import PGN are also capable of importing non-PGN files containing characters !, ?, and similar (many of which are unicode glyphs rather than ASCII characters)."

Sorry, you are wrong again. Actually I have carefully spoken about _exported_ PGN all the way long, because to _imported_ PGNs other rules apply.

Namely:

Import format PGN allows for the use of traditional suffix annotations for moves. There are exactly six such annotations available: "!", "?", "!!", "!?","?!", and "??". At most one such suffix annotation may appear per move, and if present, it is always the last part of the move symbol.

Source:

www.chessclub.com/user/help/PGN-spec

Furthermore:

There are two formats in the PGN specification, the "import" format and the "export" format. The import format describes data that may have been prepared by hand, and is intentionally lax; a program that can read PGN data should be able to handle the somewhat lax import format. The export format is rather strict and describes data prepared under program control, similar to a pretty printed source program reformatted by a compiler. The export format representations generated by different programs on the same computer should be exactly equivalent, byte for byte.

Source:

en.wikipedia.org/wiki/Portable_Game_Notation

"Actually I have carefully spoken about _exported_ PGN"

Pardon me for not immediately recognizing that by "exported PGN" you were referring to the export format. When you stated "I have seen no exported PGN in my life that implements this rule," I assumed you've never used Fritz or similar which actually conform to the specification (as well as specifying their own format).

I also assumed that because you haven't mentioned it, you are unfamiliar with CIF and C/CIF designed to be an easy PGN alternative: http://ccif.sourceforge.net/faq.html . Am I assuming incorrectly again?

Either way, your pedantry doesn't invalidate my point that you're conflating concepts.