Trying to delete useless nodes on polylines
As the author of PLDIET, I can explain why it doesn't work in that case. It's affected by where Boundary decides to start the Polyline [I did a Boundary in the upper of the horizontal areas to the left, and PLD did straighten the resulting 3-segment top edge]. [Curiously, I find that Boundary doesn't put in vertices at those endpoints of outside things that meet the edges in all cases -- it didn't for me in the L-shaped area.]
PLD heads out from the first vertex [and it can't do anything with that -- it was written with things like contour lines in mind, which are seldom closed, and it isn't going to eliminate their endpoints]. In your example, that's the middle of the right edge, so it can't straighten through that one. It proceeds from there, and for every vertex, because of certain things about the way it analyzes, it needs to look two vertices ahead from each vertex it might be able to remove. The quarter-point vertex up from the bottom of the right edge in your example is the next-to-last one [counting the Close to the start-point as the last one], so there aren't two more from there, and it doesn't analyze that one.
I suppose it might be possible to alter it to handle the latter situation, but the former doesn't seem possible without a heck of a lot more analysis of the geometry of the Polyline. BUT:
OVERKILL has this option:
which will handle the latter situation, but also won't do anything to the start/end vertex. BUT:
Plain-old grip editing can Remove even the start-end vertex:
[Select the Polyline, hover over a grip until it turns red, and type R.]
You could run PLDIET on all such things, and it should take care of many or most situations, leaving you only to "touch up" those with this kind of problematic geometry. Or, if you do this a lot on always-rectangular and always-orthogonally-oriented areas, a routine could be written pretty easily that would just replace such resulting rectangles, no matter where they start or how many vertices may occur along any edge, with "clean" ones.
Kent Cooper, AIA 
[The Swamp wants a log-in, and I'm not a registered User there, so I don't know about that one.]
The other one looks interesting, but it's not apparent from their image whether it would eliminate the start/end vertex of a closed Polyline, if that's in the middle of a straight edge as in the OP's example.
And it looks like it depends solely on the lengths of edges, straightening only series of edges shorter than a specified length. But in certain circumstances such as the OP's situation, you might need, in order to avoid straightening certain bends, to set the target length to a small enough distance that it wouldn't clear some collinear vertices that it should. By contrast, PLDIET [apart from the start/end-area limitation in my previous Reply] will eliminate all vertices, no matter how far apart, in a collinear stretch, no matter how long it is [I think that's part of the reason it has to look 2 vertices ahead from each one under consideration, but it's been a while...].
That question of straightening bends you don't want straightened is why PLD has a maximum-amount-of-change-in-direction setting, so [if you want] you can prevent the left image here from being turned into the right one, even if that short segment is much shorter than the target length.
Kent Cooper, AIA
Something like that may work if you're only trying to eliminate vertices in the middle of collinear stretches, and don't want to bother evaluating small degrees of bend angle or deal with the possibility of arc segments [parts of what makes PLDIET so much more complicated]. But it still won't be able to eliminate that start/end vertex in the middle of a straight side, unless something about your Appending idea is for that [I confess I don't quite understand the purpose of the Appending].
Kent Cooper, AIA
Accepted solution
Quick perusal, so I may be misreading something, but I think I see a potential issue:
Since it seems to construct a replacement Polyline that simply starts about halfway around the original one, might it not sometimes end up with its new start/end vertex in the middle of a different straight edge, with the same effect that PLD can't straighten across it?
Kent Cooper, AIA
@Anonymous wrote:
Kent1Cooper I've been trying to get access to your lisp - it sounds like the perfect solution! However, not seeing places online to download it anymore. Is it still available / do you know if it still runs in ACAD 2018?
Try >this<, which should be the same as the link in Message 1.
Kent Cooper, AIA
@Kent1Cooper wrote:
@Anonymous wrote:
.... Is it still available / do you know if it still runs in ACAD 2018?
Try >this<, which should be the same as the link in Message 1.
... or, the attached, which is the same except for having the (vl-load-com) line added that you will need if it hasn't been done already in your current session.
And I just tried it in Acad2019, successfully.
Kent Cooper, AIA
@Kent1Cooper wrote:
.... for every vertex, because of certain things about the way it analyzes, it needs to look two vertices ahead from each vertex it might be able to remove. The quarter-point vertex up from the bottom of the right edge in your example is the next-to-last one [counting the Close to the start-point as the last one], so there aren't two more from there, and it doesn't analyze that one.
I suppose it might be possible to alter it to handle the latter situation....
Updated version >here< handles that situation.
Kent Cooper, AIA