(Possible test cases moved under own heading below.)

Slightly related to MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.

Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common MC-7196 is difficult.

However, explanation of mistake in the code might suffice...

Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.

The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.

If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.

Here is the bad code, with my variable name interpretations:

double xDeltaToChunkCenter = startX - chunkCenterX;
double zDeltaToChunkCenter = startZ - chunkCenterZ;
double remainingLength = (double)(fullLength - currentDistance);
double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F);

if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) {
    return;
}

Exactly equal bug exists in the MapGenCaves class.

The fix

double xDeltaToChunkCenter = startX - chunkCenterX;
double zDeltaToChunkCenter = startZ - chunkCenterZ;
double remainingLength = (double)(fullLength - currentDistance);
double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F);
double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter;
double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore);
if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) {
    return;
}

That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.

Possible test cases

From Jens-Oliver Tofahrn, looks like possibly at least 3 "cuts" near each other; tp goes right in there, dark place, get torch:
Demo seed "North Carolina" or -343522682, F3-n, F3-g
/tp @s -48.42 18.94 0.10 -463.95 55.80

Multiple cuts near each other, the first place even has two cuts in the same view:
Seed 1479112774635546442
/tp @p -440 62 11 107 20
/tp @p -457 62 18 -140 19
/tp @p -447 62 -96 114 -12

(Wery Old: Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)

History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196 when it was still effective for overworld, too), based on observed differences while enabling either fix separately.