BUG #8094: psql prompt variable and command substitution broken

The following bug has been logged on the website:

Bug reference: 8094
Logged by: Noah Yetter
Email address: nyetter(at)gmail(dot)com
PostgreSQL version: 9.2.4
Operating system: Linux (Amazon AMI Linux x64, kernel 3.2.39)
Description:

My psql PROMPT1, set through /etc/sysconfig/pgsql/psqlrc, is the following:
h:%M%040d:%/%040U:%n%040AC:%:AUTOCOMMIT:%040TX:%x%012%R%#%040

Here is the behavior I got under 9.1.5:
$ psql -U postgres
Timing is on.
psql (9.1.5)
Type "help" for help.

h:[local] d:postgres U:postgres AC:on TX:
=# \set AUTOCOMMIT off
h:[local] d:postgres U:postgres AC:off TX:
=# \set AUTOCOMMIT on
h:[local] d:postgres U:postgres AC:on TX:
=#

As intended, the variable substitution %:AUTOCOMMIT: causes the prompt to
show the current value of AUTOCOMMIT.

Here is the behavior under 9.2.4:
$ psql -U postgres
Timing is on.
psql (9.2.3)
Type "help" for help.

h:[local] d:postgres U:postgres AC:on: TX:
=# \set AUTOCOMMIT off
h:[local] d:postgres U:postgres AC:on: TX:
=# \set AUTOCOMMIT on
h:[local] d:postgres U:postgres AC:on: TX:
=#

Here you can see the variable substitution is not functioning, in that
changes to the variable value are not reflected in the prompt. Additionally
the trailing colon of the variable substitution pattern is leaking into the
prompt. Re-setting the prompt variable does cause the substitution though:
h:[local] d:postgres U:postgres AC:on: TX:
=# \set AUTOCOMMIT off
h:[local] d:postgres U:postgres AC:on: TX:
=# \set PROMPT1
h:%M%040d:%/%040U:%n%040AC:%:AUTOCOMMIT:%040TX:%x%012%R%#%040
h:[local] d:postgres U:postgres AC:off: TX:
=#

Also, inspecting the value of PROMPT1 suggests that the substitution may be
occurring when the variable is set rather than when it is drawn:
h:[local] d:postgres U:postgres AC:off: TX:
=# \echo :PROMPT1
h:%M%040d:%/%040U:%n%040AC:%off:%040TX:%x%012%R%#%040

Note that it says "%off:" instead of "%:AUTOCOMMIT:" which is what was set.

Command substitution using %`command` is broken in precisely the same way.

This bug also manifests in the 9.2.2 Windows x64 version of psql which I
have on my workstation.

Output of version():
PostgreSQL 9.2.3 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.6.2
20111027 (Red Hat 4.6.2-2), 64-bit

Output of uname -a:
Linux host.name.redacted 3.2.39-6.88.amzn1.x86_64 #1 SMP Sat Mar 2 05:13:37
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

--
Noah Yetter
Data Architect @ Craftsy