Major Description
Lets say we have the following rule
cond %{HEADER:foo} /bar/
add-header Baz1 1
cond %{HEADER:foo} =bar
add-header Baz2 2
There are some weird interactions with how this works today, so lets start with that:
some request headers, and outcomes
# matches 1 and 2 foo: bar # matches both 1 and 2 foo: bar foo: baz # matches nothing foo: baz foo: bar
So the main problem we see here is that the second value is completely ignored all of the time-- which is bad 
And when we get more complicated there are some more issues. In HTTP headers have to be collapsible into a single line (http://tools.ietf.org/html/rfc2616#section-4.2). This means that 2 headers with values `foo` and `bar` must be equivalent to a single header with value `foo,bar`. With that information, lets assume the downstream actually sent the values in the same header (which is completely valid-- and has to be treated the same according to the RFC).
# matches 1 foo: bar,baz # matches 1 foo: baz,bar
So this means we can boil down the problem into 2 pieces: (1) duplicate headers are ignored and (2) collapsed headers are treated differently than separate headers.
So, I have a PR open on github (https://github.com/apache/trafficserver/pull/284) which combines the headers (according to the RFC) before passing it to the conditional's matcher. Here are the outcomes of the same set of headers
# matches 1 and 2 foo: bar # matches 1 foo: bar foo: baz # matches 1 foo: baz foo: bar # matches 1 foo: bar,baz # matches 1 foo: baz,bar
And with this we have fixed both (1) taking the second header value as well as (2) treating collapsed and non-collapsed the same.