Since I believe you should use pgfkeys for everything (programming-related) let me submit a second answer with the same general behavior as the first. The only difference in the interface is that \NewEnvCode takes just one argument, which is a comma-separated list of key-value pairs <env> = <code> (put <code> in braces if it has commas or equals signs). The difference in coding is readily apparent:
\documentclass{article}
\usepackage{filecontents}
% Simulated package file
\begin{filecontents}{pgfkeys-envcode.sty}
\RequirePackage{pgfkeys}
\pgfkeys{
/envcode/.is family, /envcode,
define/.is family,
code/.is family,
}
\pgfkeys{
/envcode/define,
.unknown/.style = {
/envcode/code/\pgfkeyscurrentname/.code={#1},
},
}
\AtBeginDocument{\MakeDefault}
\newcommand\NewEnvCode[1]{%
\pgfkeys{/envcode/define,#1}%
}
\newcommand\MakeDefault{%
\pgfkeys{/envcode/code/.unknown/.style/.expanded=\@currenvir}%
}
\newcommand\RunEnvCode{%
\pgfkeys{/envcode/code,\@currenvir}%
}
\end{filecontents}
\usepackage{pgfkeys-envcode}
\NewEnvCode{
document = default code,
equation = {\int_{-\infty}^\infty e^{-x^2/2} dx = \sqrt{2\pi}},
itemize = itemize!,
}
\begin{document}
\RunEnvCode
\begin{equation}
\RunEnvCode
\end{equation}
\begin{enumerate}
\item \RunEnvCode
\end{enumerate}
\begin{itemize}
\item \RunEnvCode
\item
\begin{enumerate}
\item \RunEnvCode
\end{enumerate}
\item \MakeDefault
\begin{enumerate}
\item \RunEnvCode
\end{enumerate}
\end{itemize}
\end{document}
Here's how it works:
Recall that pgfkeys has the notion of a "directory tree" of keys, and that its keys can perform quite general functions other than storing values: for example, they can invoke other keys, and there is a mechanism for dealing with unknown keys via a default search path. This is the mechanism I exploit to get the "default" behavior.
Any key <env> = <code> you pass to \NewEnvCode defines a key in the directory /envcode/code with the name <env>, and sets it to execute <code> when run; when you call \RunEnvCode, it tries to execute this key with <env> = \@currenvir.
When /envcode/code/<env> does not exist, the default "handler" /envcode/code/.unknown is called instead. This is set up by \MakeDefault, which says that it should have the "style" \@currenvir (completely expanded at "compile" time), meaning that it just calls the key of that name, e.g. "document". I made it so that \MakeDefault is called right after \begin{document}, so that with no other changes, the default code is for "document", which you should set up.
This same mechanism is responsible for the workings of \NewEnvCode itself: each key you give it is executed under the directory /envcode/define, which never has any keys defined in it. The unknown handler there always runs, and we ask it to set up a key in /envcode/code of the same name, whose "code" is <code>. This is a convenience for the user, so you don't have to write /.code after everything.
As you can see, the behavior you are looking for is basically equivalent to the lookup behavior of pgfkeys, so this is a pretty appropriate tool in addition to being superior programming-wise to the funny things that happen in TeX. Obviously it's a lot more complicated behind the scenes; every one of these macros probably expands to dozens of internal ones before eventually doing effectively what I wrote in my other answer. However, this code is self-documenting and, because pgfkeys is so flexible, much more easily extendable.
\begin{enva} \begin{tt} \ifenv{enva}{THIS IS RIGHT}{I AM WRONG}\end{tt}\end{enva}. – Dec 31 '11 at 18:56begin{..}defines the\@currenvir. In other cases you must work with flags ala\newif\ifenvaand set the flags at the beginning of the environment. – Marco Daniel Dec 31 '11 at 18:59centerenvironment is something that users may typically want to use as an ``inbetween'' environment. – Dec 31 '11 at 19:24