Negative leap seconds will mean that there will be UNIX timestamp value that is invalid. What should systems do when they encounter such value? Generally UNIX time -> UTC conversion is considered to be infallible, negative leap changes that.
Normally, nothing. The invalid UNIX timestamp can still be converted to a (also invalid) UTC timestamp, without needing to know whether or not it is valid. However, when you want to convert to a SI timestamp (e.g. in order to add or subtract a number of SI seconds), then you do have to consider it; in this case it might be an error.
Similar things apply with a positive leap second, although in that case the result is not an error. However, for positive leap seconds, when you are converting a UTC time in parts, into the UNIX timestamp, there is an additional time 23:59:60 for some dates. This can still be converted, although if you have a separate field for nanoseconds (or other divisions of a second) in the original UTC timestamp, then you will have to either subtract one second from the subsecond divisions, or change :60 to :59 and add one second.
And, then again, you will also have to consider the leap second when dealing with SI seconds, whether they are positive or negative leap seconds. You will get the wrong answer if you fail to consider leap seconds either way (although in the case of negative leap seconds, there might not be a "right answer" in some cases).
But, even if you do not consider these things, the timestamps will not be off by more than one second in either direction; this is not normally a problem, although in some cases it might be (which are the cases when it will be important to deal with leap seconds properly).
Sure, in theory the string 20xx-12-31T23:59:59 should never be created. But if it is created, so what? A time span is off by a second, in the positive direction. Not good, but shrug. I'm not saying it's a good thing. At time recording it's like the computer froze for a second.
Compare this to the problem of there being a unix timestamp integer that refers to two different times, which is what naive positive leap second implementations resulted in. Real time spans being impossibly negative.
Positive leap seconds are orders of magnitude worse.
Unless you're writing time keeping software, negative leap seconds can be ignored and will be "just fine". And if you are writing time keeping or benchmarking software, then this is just another thing to not have a misconception about.
> Generally UNIX time -> UTC conversion is considered to be infallible
And generally there's two seconds between N and N+2.
