I'm the one that mentioned that 500LoC thing. Sorry to horrify you, I wasn't talking about 500 LoC files, I referred to "units" (function definitions, data structures, etc) *within* (often much larger) files.

Your preference for under 100LoC files, a few thousand LoC total for Python programming just confirms that block-by-indentation makes Python unsuited for "large and complicated systems".

You'll easily reach 500LoC just validating a not too complicated web form (for example, to fill an invoice). Splitting that code would make it much more difficult to maintain.

I don't much like Python, but I don't regard it as a toy language.

I'd also like to commend getuid()'s wise two words. Spoken as a true programmer in the saddle, sir!

Sorry, not as good as any other:

1) "white space" (in truth, only horizontal white space) is by definition invisible. So using *only* white space to signify a block is in fact assigning semantics to the invisible
2) ... compounded by the fact that the TAB character (still invisible, just like SPACE) has different widths depending on the horizontal position, the editor configuration, and so on
3) ... therefore, what you get is a programming language that does not support reliable auto-indentation on editors
4) ... not enough redundancy symbolizing blocks so that trivial structure errors are caught at the lexical analysis step
5) ... nor enables the use of folding editors: when there is a fair amount of block nesting you can't fold blocks to gain an appreciation of the code structure at a selected depth

So, essentially you are getting readability (if you are of that opinion) at the expense of significance. But that readability quickly vanishes when you have longish source that doesn't fit in one screen or page.
If Python added (optional) braces to define blocks, I'd switch to it in a second. By optional I mean "if the first non-blank character in a line is a "'{', then that describes the start of a block within which indentation is non-significant until the closing '}' appears". You'd still be able to auto-indent, or to miss spaces or tabs, and the code would still be understandable by the compiler.
As it is, a mere, trivial 500 LoC unit becomes a nightmare to debug at a single glance. Me, I've got better things to do than counting invisible stuff.

"reduce fragmentation" = "increase unification"

Reminds me of Bismark's policy for the Unification of Germany, Prussia being MS.

Next step: exerting the power of that unification to change Web standards at will.

It doesn't require two versions of perl. perl7 can be a symlink to plain perl. Different behaviour based on the program name, like grep/egrep/fgrep, It also does not require any change at all on existing scripts.

This can be solved with a single character:
#!/usr/bin/perl
is Perl 5 compatibility mode.
#!/usr/bin/perl7
is Perl 7 mode.
... or perhaps this is not simple enough...