`sun.nio.cs.HKSCS.Encoder` extends from `sun.nio.cs.DoubleByte.Encoder`, which uses `DoubleByte.Encoder::repl` to store the replacement character. When `HKSCS.Encoder#implReplaceWith(byte[] newReplacement)` is called to set the replacement character, it only sets the private one, i.e., `HKSCS.Encoder::repl`. When `HKSCS.Encoder::encodeFromLatin1` gets called, it delegates to `DoubleByte.Encoder::encodeFromLatin1`, which uses `DoubleByte.Encoder::repl` and that does not match the `HKSCS.Encoder::repl`. Effectively, replacement character does not get picked up when `HKSCS.Encoder::encodeFromLatin1` is used.

This anomaly can be reproduced with the following simple JTreg test:

```
ArrayEncoder ae = (ArrayEncoder) Charset.forName("Big5-HKSCS").newEncoder()
                .onMalformedInput(CodingErrorAction.REPLACE)
                .onUnmappableCharacter(CodingErrorAction.REPLACE)
                .replaceWith(new byte[]{65});
        var da = new byte[2];
        ae.encodeFromLatin1(new byte[]{0x2D, (byte) 0xD8}, 0, 2, da);
        if (da[0] != 0x2D || da[1] != 65) {
            throw new RuntimeException("unexpected encoding result: [%d, %d]".formatted(da[0], da[1]));
        }
```