Thanks, have they expressed that this is what they'd like to check for? Do any other terminals export their versions?

In D12621#257226, @hindenburg wrote:

Thanks, have they expressed that this is what they'd like to check for? Do any other terminals export their versions?

Both XTERM and VTE export XTERM_VERSION AND VTE_VERSION respectivley; and there's this commit where there's a condition based on vte_version:
https://github.com/neovim/neovim/commit/809420233c591c81aede48679a42fce90e75bb6f#diff-3ac88981a139ac0eee448a6bd19c7569R1433

Ok I should have explained better; do they want XX.YY.ZZ or something else? I notice xterm and vte just use a # (without .)

In D12621#257530, @hindenburg wrote:

Ok I should have explained better; do they want XX.YY.ZZ or something else? I notice xterm and vte just use a # (without .)

They didn't actually ask for this change (the upstream issue I opened to notify upstream of adding support for DECSCUSR was closed as there's no easy way for upstream to test the version of the konsole terminal they're running under).

XTerm doesn't seem to have point releases, so version (patch) numbers don't have dots at all.

As you indicated, VTE exports the version as a numeric string without the . ; this seems reasonable as this makes much easier to use the version env var in an arithmetic expression in the shell (bash's arithmetic operators only support comparing between integers).

Even bash has BASH_VERSINFO which is an array, for example on my setup:

BASH_VERSINFO=([0]="4" [1]="4" [2]="19" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu")

So it does make sense to export the konsole version as e.g.:
180770

if you agree I'll update the diff.

That sounds great - thanks 180770

Thanks, you could use remove to simplify it slightly.

In D12621#258165, @hindenburg wrote:

Thanks, you could use remove to simplify it slightly.

Good point; done.