I found very weird discrepancy regarding Tcl_FSStat using 8.6 under Windows for file sub-commands (that use GetStatBuf), depending from used path by "built-in Windows names with dir path and extension".

The explanation, what happens, could be provided from this script:
<code><pre style="padding-left:10pt; font-size:85%">
proc test_fs_nef {{path {}} {fn this-file-does-not-exists.txt}} {
  puts "[set fn [file join $path $fn]] ..."
  puts -nonewline [format [string repeat "  %-8s: %s\n" 5] \
    atime [catch {file atime $fn} r] $r \
    mtime [catch {file mtime $fn} r] $r \
    size  [catch {file size $fn} r] $r \
    stat  [catch {file stat $fn stat} r] "$r [array get stat]" \
    type  [catch {file type $fn} r] $r \
  ]
}

puts [test_fs_nef [info library]]
puts [test_fs_nef [info library] CON.txt]

puts [test_fs_nef $::env(TEMP)]
puts [test_fs_nef $::env(TEMP) CON.txt]; ## here something goes broken!!!

results in:
<code><pre style="padding-left:10pt; font-size:85%">
...</b>
  atime   : [1] could not read no such file or directory
  mtime   : [1] could not read no such file or directory
  size    : [1] could not read no such file or directory
  stat    : [1] could not read no such file or directory
  type    : [1] could not read no such file or directory

...</b>
  atime   : [1] could not read no such file or directory
  mtime   : [1] could not read no such file or directory
  size    : [1] could not read no such file or directory
  stat    : [1] could not read no such file or directory
  type    : [1] could not read no such file or directory

...</b>
  atime   : [1] could not read no such file or directory
  mtime   : [1] could not read no such file or directory
  size    : [1] could not read no such file or directory
  stat    : [1] could not read no such file or directory
  type    : [1] could not read no such file or directory
<b style="color:red">
...
  atime   : [1] could not get access time for file
  mtime   : [1] could not get modification time for file
  size    : [0] 0
  stat    : [0]  mtime 0 atime 0 gid 0 nlink 0 mode 8630 type characterSpecial ctime 0 uid 0 ino 0 size 0 dev -1
  type    : [0] characterSpecial
</b>


The guess that something may be wrong on Windows self (e. g. other return code from WinAPI) has not been confirmed:
<b>the same script executed for 8.5th returns the expected results in the last case</b> (exactly as for all 3 first cases).
It's not the path and file-name alone, because this weird behavior happens only by <b>the combination temp-path together with "CON.txt"</b>.

This reflects why the several cmdAH-test-cases fail if used without -tmpdir and successful with -tmpdir parameter.
<code><pre style="padding-left:10pt; font-size:85%">
.\tclsh86 -file "cmdAH.*"
  cmdAH-20.7.1 FAILED
  cmdAH-24.14.1 FAILED
  cmdAH-27.4.1 FAILED
  cmdAH-28.13.1 FAILED
  cmdAH-29.6.1 FAILED
Total   320     Passed  140     Skipped 175     Failed  5

.\tclsh86 -file "cmdAH.*" -tmpdir %TEMP%
Total   320     Passed  145     Skipped 175     Failed  0