Replace string literals with defined constants

In Drupal arrays and API calls we keep reusing agreed-upon string literals again and again; I would argue that this is a cause for avoidable coding errors and a productivity handicap, and that using clearly delineated define'd constants instead of literals would help new and experienced contributors alike.

The benefits would be:

Reduction in coding errors:

It is easy to mis-type a string literal (like "feild") while reusing the same literal again and again; having a solid token to validate against rather than a soft identifier reduces these types of objective errors.

Self-validation:

If I use a string literal with a typo in it no tool will let me know what to look for. Yet if I use a constant with a typo in it and that constant doesn't exist ('node_field' vs NODE_FIELD let's say) and set PHP to issue struct warnings, then I can pinpoint my error right away.

Ease of documentation:

By having constants I can look them up more easily on api.drupal.org than if I need to look for string literal explanations in various api method documentations. If I am in a code editor and need a quick memory jog as to what the constant can be I must parse through the code. By forcing module developers to use clearly delineated blocks of define() statements (and const at the top of classes) I can quickly see which option might be available to me in any given context. Constants make the implicit explicit.

Dynamic evolution:

Let's say I need to clarify the use of a string literal which, in a previous version, was unclear or ambiguous ("callback" for example, which could mean any form of callback in any context). With agreed-upon string literals I am stuck and cannot make my code clearer (to use, for example, "implementation method" in menus that are simply not callbacks at all) as the implicit agreement is set in stone. Yet if I "evolve" a literal using defines() I am free to keep the original constant label AND define a new constant label that both equate to the same literal and help teh code evolve without breaking existing code.

Namespace clarity & compatibility:

Let's say, for example, that two modules use the same string literal ('revision' for example) but do so in different contexts (one for a standard node revision, one for a boolean that indicates whether a decision to mark a node for revision in an editorial workflow has been made) I cannot tell these apart just by looking at the code. But NODE_REVISION and EDITORIAL_REVISION make this clear. And if Drupal Core goes OO, then NODE::REVISION is equally clear and will not require that we retrain developers in the future to a new agreement.

Translation help:

If all code-related strings are removed and replaced by constants, it makes it much easier for developers (and the Coder module) to pinpoint potentially untranslated literal strings that could be displayed to the user.

Backwards compatible:

In a pinch or for a Q&D hack implementation, using literals is still possible through this proposal.

Speculative benefits:

(someone more familiar with the PHP runtime internals might confirm or rebuke this)

Memory consumption reduction: if string constants found in code are not reference-counted and reduced to a single item in memory, then using multiple string constants will bloat the execution context memory space whereas using constants would save space.