Thank you, Stefan.
Actually, I already knew about the deferred .vs. immediate issue. In my post, the first CA, the one which grabbed the value and stashed it, was "immediate", and the other, which later used the stashed value, was "deferred". So the problem seems to go deeper than that.
After perusing the wonderful world of MSDN, I noticed that in the discussion re:MSi*etProperty, there is some concern over the format of "string" type data passed via these methods. That raised some concern in my own mind, since InstallScript (unlike, for example, VB) seems to give you no control over which of the several Windows string formats are used.
However, while searching for an answer for that one, I returned to Bob Baker's book, and tried something I had previously avoided, the "type 51" CA. (It is well named, being about as inscrutable and obscure as the famous Area 51 in Nevada - Sorry, Bob, your book helps, but it still isn't real clear). Anyway, after several attempts and re-readings, I managed to get this technique to work.
What I found to be confusing about Type 51 is that the thing you must designate as the "source" in the CA Wizard, is actually the name of the CA which is to receive the data, while the "target" is the name of the property whose value you which to pass. They seemed reversed to me. Also, it is not clear why the name of the receiving CA is critical - this technique would nod work until I designated the second CA's name as the "source", rather than the property name CustomActionData.
At any rate, I'm off and running once again. Thanks again for your response.