Otdfbt

It is my understanding that in ifxxy xx else yy fi, ifx does NOT expand its arguments. If you want ifx to compare the expanded values of x and y, then we need to do the expansion ourselves before feeding them to ifx:

edefxpndXx
edefxpndYy
ifxxpndXxpndY xx else yy fi

asedef does this expansion for us. This is frequently the case when x and y are the arguments in a macro so we really have no idea what kind of quantity they represent.

I was adapting a code snippet I found in user2478's answer to the TeX-SE question Why does this simple ifx test fail? and came up with the following MWE:

documentclassarticle
usepackage[svgnames]xcolor % to get named colors

begindocument

chardefmysteryletter=`H
% loop through A-Z to find out the mystery letter
newcountcurrentchar

currentchar=`A
loop
 chardeftemp=thecurrentchar
 edeftmptemp%
 ifxmysterylettertemp colorRedbftempelsetempfi
 advance currentchar by 1
 unlessifnum currentchar>90
repeat

enddocument

which, when compiled, generated the output:

which actually is the desired output, but it should NOT have been! I added the statement edeftmptemp to get the 'expanded' version of temp intending to change the temp argument to the ifx command to tmp but had not when this document was compiled. Lo and behold, the desired result was printed out! This lead me to believe that the expansion performed by the edeftmptemp statement was not required, so it was commented out and the document recompiled. This gave the wrong result; the letter H was not bold or red

I note that removing the comment character from the end of the edef command had the expected affect of adding a space between each letter, but did not prevent the 'H' from being found and highlighted.

So my question is this: How does the unused expansion of temp by the edef statement change the comparison performed by the ifx command? What am I missing here?

 chardeftemp=thecurrentchar
 edeftmptemp%

tokens defined via chardef are not expandable, so edeftmptemp is the same as deftmptemp

It is not clear why you do not expect ifxmysterylettertemp not to be true if the two tokens are both defined via chardef with the same number?

I guess your modified version was equivalent to

 chardeftemp=thecurrentchar
 ifxmysterylettertemp 

There the ifx test happens before the assignment while looking to end the number, you need

 chardeftemp=thecurrentcharrelax
 ifxmysterylettertemp 

or

 chardeftemp=currentchar
 ifxmysterylettertemp 

So your edef was just acting like relax terminating the chardef assignment.