This algorithm sounds like it has a dreadful worst-case complexity. It can have to parse the whole file to give the intended result (eg. in the case of a dense table, when deleting a character at the end of the longest cell of a column).
It also has terrible partial results. For instance, removing the tab after `cell-missing` in the example triggers a weird alignment.
That is too bad, since the idea is bright.
PS. This is off-topic, but I cannot create a new thread on it, since it was submitted to HN six years ago and that old thread is locked: https://news.ycombinator.com/item?id=333626
FWIW, it's not that particular implementation that I'm in favour of. As you say, it has some issues.
Also, while the page I linked to was the first time I saw anyone offer a convenient name and write-up to cite, I should acknowledge that there had been discussions about using tab widths that varied by context long before that page was written. Many editors have provided related functionality where hitting tab once would automatically align your code blocks, function parameters, etc.
I suspect that for anything closer to the specific elastic tabstops idea I cited to become established, we'd need a distinct character rather than reusing ASCII spaces and tabs. This could work rather like the way various typesetting systems and DTP packages have "align to here" markers that don't necessarily introduce any extra horizontal space themselves but do indicate that consistency should be enforced across related lines.
I personally think that a standardised character like that and support for it in tools like editors and diff displays could bring several modest benefits: aside from the immediate convenience of aligning code more neatly if that's helpful, it could actually clean up a lot of whitespace-based diffs that tend to confuse tools today without necessarily having to ignore all whitespace, and of course it would improve the usefulness of proportional fonts when reading code, which I think is where we came in.
It also has terrible partial results. For instance, removing the tab after `cell-missing` in the example triggers a weird alignment.
That is too bad, since the idea is bright.
PS. This is off-topic, but I cannot create a new thread on it, since it was submitted to HN six years ago and that old thread is locked: https://news.ycombinator.com/item?id=333626