This is odd. I have defined the following prompt in zsh:

local user_host='%{$terminfo[bold]$fg[green]%}%n @ %m%{$reset_color%}'
local current_dir='%{$terminfo[bold]$fg[blue]%} %~%{$reset_color%}'
local git_branch='$(git_prompt_info)%{$reset_color%}'
local return_code="%(?..%{$fg[red]%}%? ↵%{$reset_color%})"

PROMPT="╭─${user_host} %D{[%a, %b %d %I:%M:%S]} ${current_dir} ${git_branch}
╰─%B$%b "
RPS1="${return_code}"

It works great on gnome-terminal as well as in an ansi-term terminal in Emacs (M-x ansi-term) - see the example below:

However, it does not work well under multi-term in Emacs as you can see below:

I thought multi-term would be capable of interpreting the same set of escape characters that a terminal like gnome-terminal or ansi-term does. Why is it not interpreting the escape characters returned by git-prompt_info and others correctly?

I have also tried:

• M-x set-terminal-coding-system and setting it to utf-8-unix
• TERM=eterm-color within the multi-term terminal, or before calling Emacs, etc.
• TERM= within the multi-term terminal, or before calling Emacs, etc.
• Removing any export TERM from my .zshrc

Update (January 29, 2014):

The best solution so far seems to be to do the following:

TERM=xterm-256color

but causes another problem that I have reported here: Passing escape sequences to shells within ansi-term in Emacs.

Why is it not interpreting the escape characters returned by git-prompt_info and others correctly?

The answer is most likely that multi-term just isn't prepared to accept those escape sequences, in that format, for whatever reason. This may be a configuration issue, bug, or intentional. Setting the mode to accept colors, i.e. TERM=xterm-256color, improves the situation because it then accepts color escape sequences similar to the standard format used among terminal emulators, e.g.:

RED='\033[0;31m'
NC='\033[0m' # No Color
echo "I ${RED}love${NC} Stack Overflow\n" # this output IS NOT interpreting the escapes
echo -e "I ${RED}love${NC} Stack Overflow\n" # this output IS interpreting them

^{code borrowed from here}

the salient part is the [0;31m for color, which is referenced in the linked thread in "Update 2" of your other question, asking why lines are printed out that begin with 4m which is part of this color escape sequence.

Here is more info, with a relevant excerpt:

Thus it is your terminal emulator that understands colors. Your terminal emulator understands that \033[0;36m is cyan, but another terminal emulator might use an entirely different set of characters for cyan (though no sane terminal emulator would flaunt the standard and do this). This is the reason for tput. When you run tput setaf 6, tput is going to look up your terminal's escape codes for the color 6 (cyan), and output that escape code.

I suspect, in your other question, the reason that alt+b and alt+f aren't working in your other question is due to the terminal width count being off because of improper interpretation of these escape sequences which are supposed to be non-printing or zero-width. I haven't messed with multi-term a lot but the solution may involve using tput or similar to allow it to properly understand the escape sequences.

Possible relevant troubleshooting info