If one would test append with -singleproc 1, test append-3.10 fails, however it shows the same internal representation.

Also testing of `append-3.10` solely doesn't fail, however by match `append-3.*` it does.<br/>
By an attempt to debug it, I could reduce the failing command to exactly 2 tests:

```
./tcltest.sh -file 'append.test' -singleproc 1 -match 'append-3.6 append-3.10' -verbose tp
```

(again, without -singleproc it'd not fail at all)


Strange is, if I add small output for debug to [tcltest::CompareStrings, (line

```
puts "***[tcl::unsupported::representation $expected]\n***[tcl::unsupported::representation $actual]\n***[expr {$expected eq $actual}]***"
```

and test it with above-mentioned command, I see:

```
...
append.test
---- append-3.6 start
***value is a pure string with a refcount of 10, object pointer at 0xd5ad60, string representation "😂"
***value is a utf32string with a refcount of 6, object pointer at 0xd62238, internal representation 0x38a2898:0x0, no string representation
***1***
++++ append-3.6 PASSED
---- append-3.10 start
***value is a utf32string with a refcount of 8, object pointer at 0xd61db8, internal representation 0x38a0990:0x0, string representation "😂"
***value is a utf32string with a refcount of 6, object pointer at 0xd62238, internal representation 0x38a2898:0x0, no string representation
***0***

==== append-3.10 append surrogates FAILED
==== Contents of test case:

    set x \uD83D
    string range $x 0 end
    append x \uDE02

---- Result was:
\U0001F602
---- Result should have been (exact matching):
\U0001F602
==== append-3.10 FAILED

```

(so there is no string representation in the 2nd object in both cases, but one succeeds, however another doesn't)

Trying to rewrite the test to a script to find the heisenbug, became confused still more - it changes the result vice versa (now in 3.6 it is not equal, but in 3.10 it is:

```
  # 3.6:
  set x \uDE02
  puts 3.6\t[expr {[set x \uD83D$x] eq
  # 3.10:
  set x \uD83D
  string range $x 0 end
  puts 3.10\t[expr {[append x \uDE02] eq [string range 0 end]}]
```

so it results to:

```
  3.6     0
  3.10    1
```

Weird.

Can someone (familiar with the new unicode or utf) take a closer look here, please.

My build was for windows, x86 mingw toolchain with gcc 11.2.0, configured as:

```
$ ../configure --disable-zipfs --enable-time64bit # (--disable-64bit, 'cause x86)
```
(didn't tested for other yet).