It is said that line prefixes in the form of: TAB* SPC{0,tw-1}
are the best of both world.
This is false.
First, you would need an editor to enforce it.
But it doesn't even solve the first problem of TAB, that their width
varies depending on tools and devices.
The problem is that the sequence of spaces must be of a length less than
the TAB width. So if you start with tw₀ and have sequences of SPC of
length tw₀-1, and you read/process the file on another system using
tw₁<tw₀, then you will get wrong indentations.
Furthermore, when you allow TAB in source files, you may also use them
to align columns of code, eg. to align variable names in one column, and
types in another column. And for those TAB in the middle of the lines,
the above rule is helpless, and again, you will get wrong indentations
in other environments, but also IN THE SAME ENVIRONMENT, where the TAB
width is kept constant, as soon as you use a different FONT, notably
when you use non-proportional fonts.
I know that it may seem heritic to use non-proportional fonts for code,
but the reality is that it can work very well, as long as you solve in
the IDE those problems of indentation, both prefix and inside a line.
And, it means the editor will have to compute the layout all the time,
from the parse tree.
Which leads me to the conclusion that the origin of a lot of problems is
the fact that we save "source" files that are used as-is both for
human presentation/edition and for machine processing (compiling). I
would propose the alternative to save the programs eg. in the form of an
abstract syntactic tree (let's say lisp S-expressions), and each time it
is loaded in an IDE/editor, it would be unparsed into the specific
syntactic and layout/indenting preferences of the programmer; and when
saved, the programmer specific syntax would be parsed, and the
S-expression syntactic tree would be saved to the file. Machine
processing can use directly these S-expression forms.