Suppose, not hypothetically, that you have just performed an operating system upgrade that upgraded the version of xterm. On the surface, this version of xterm looks just like the old one; for example, your default xterm looks like this, which is normal and how it used to.

However, you also have 'root xterms' for your su sessions, with a red foreground to make them stand out as special (cf). When you call one of these up for the first time, it looks like this.

That obtrusive, ugly black border doesn't belong there, and it didn't used to be there in older versions of xterm (and this is not a window manager decoration; xterm draws it itself, inside any window manager framing). This border appears because of a change in xterm patch #334:

• color the inner border using the same borderColor as the outer border, rather than filling with the VT100's default background.

What this innocent sounding change appears to do is colour this inner border in your default foreground colour, whatever that is (black, in my case, since my default xterm colours are black on white), unless you are using entirely default colours. The moment you set any or all of foreground, background, or cursor colour, you get the border drawn in. In xterm patch #334 (which is the version in Fedora 29), the only way to avoid this is to explicitly set the border colour to your background colour, whatever that is for any particular xterm.

(The border colour may be set with either the borderColor X resource or the -bd command line argument. Which one you use depends on how you're changing the other colours; for my sins, I have a mixture, so I get to make changes all over.)

In xterm patch #335, this behavior was effectively reversed (as far as I can tell), although the patch notes will not tell you that. Instead you need to consult the xterm manpage, which now says that by default xterm is back to filling the inner border with the background color and you can set the colorInnerBorder resource to change that. Of course, the default xterm resources that your Unix ships may be altered to change this; if they are, you will need to change things back to restore the old default behavior.

The good news is that patch #335 came out only a few days after patch #334. The bad news is that xterm #334 made it into at least one Unix (specifically, Fedora 29). Hopefully your Unix will skip past #334, and also hopefully it won't pick a version of xterm that has other surprises.

As a look at the xterm changelog will show you, xterm undergoes a lot more change than you might expect in such an old and venerable program (certainly more change than I expect, at least). Some of these changes are fixes for bugs and issues, and some of them are useful improvements, but every so often there are things like this change that make me less than happy.

(There was the xterm patch #301 change to $SHELL handling in 2015, for example, which was later recognized as flawed and augmented with the validShells X resource in xterm patch #334. Yes, the same patch that added this new behavior. The irony is thick.)

PS: It is worth looking at the XTerm default X resources file that your Unix provides along with its xterm, because historically various packagers and distributors have been unable to keep their hands off it. The upstream XTerm default resources have been quite stable over the years, a stability that's appreciated by long-term xterm users like me; distribution ones, not so much.