Could postgres be much cleaner if a future release skipped backward compatibility?

Tom Lane wrote:
> What are the probabilities that the OpenACSes of the world will just
> set the value to "backward compatible" instead of touching their code?

Would postgres get considerably cleaner if a hypothetical 9.0 release
skipped backward compatibility and removed anything that's only
maintained for historical reasons?

I notice the docs are filled with passages like the quotes
below - which suggest that there's a fair amount of stuff
that might be done differently if it weren't for backward
compatibility.

"For historical reasons (i.e., this is clearly wrong but it's far
too late to change it), subscripting of fixed-length array types
starts from zero, rather than from one as for variable-length arrays. "

"Most of the alternative names listed in the "Aliases" column are
the names used internally by PostgreSQL for historical reasons.
In addition, some internally used or deprecated types are available,
but are not listed here. "

"Note: The name "oid2name" is historical, and is actually
rather misleading"

"Note: Native Kerberos authentication has been deprecated
and should be used only for backward compatibility."

"Old-style functions are now deprecated because of portability
problems and lack of functionality, but they are still
supported for compatibility reasons. "

"Although they still work, they are deprecated due to poor
error handling, inconvenient methods of detecting end-of-data,
and lack of support for binary or nonblocking transfers."

"The PostgreSQL usage of SELECT INTO to represent table
creation is historical. It is best to use CREATE TABLE AS
for this purpose in new code. "

"regular expression metasyntax ...
option...m: historical synonym for n"

"Such comments are more a historical artifact than a useful facility,
and their use is deprecated; use the expanded syntax instead."

"The CAST syntax conforms to SQL; the syntax with :: is historical
PostgreSQL usage."

"timeofday() is a historical PostgreSQL function."

"(This does not match non-slice behavior and is done for
historical reasons.)"

"The SQL standard requires the use of the ISO 8601 format. The name of
the "SQL" output format is a historical accident."

"attribute ... The historical way to specify optional pieces of
information about the function. "
Caution

"Caution: If the configuration parameter standard_conforming_strings
is off, then PostgreSQL recognizes backslash escapes in both regular
and escape string constants. This is for backward compatibility
with the historical"

"historical alias for stddev_samp ... historical alias for var_samp"

"For historical reasons, this variable contains two independent components"

"For historical reasons, the same function doesn't just return a
boolean result; instead it has to store the flag at the location
indicated by the third argument. "

"For historical reasons, there are two levels of notice handling,"

"Note that subscripting is 1-based, whereas for historical
reasons proargtypes is subscripted from 0 "

"The term attribute is equivalent to column and is used
for historical reasons. "

"For historical reasons, ALTER TABLE can be used with
sequences too; but the only variants of ALTER TABLE
that are allowed with sequences are...."

"While this still works, it is deprecated and the special
meaning of \. can be expected to be removed in a future release."

"Use of this parameter is deprecated as of PostgreSQL 8.3;"