This is a "why" question -- Hoping William van Weelden is watching since he has lots of related topics online ---
For quite some time, our developers have used this construct, where helpID is actually the string we plug into the Context Sensitive map GUI...not the Map ID number, the actual string. This has always worked well.
"/help/A/a_rhc.htm#" + helpID;
I did something unusual recently (at least I think so) with a result that I can't explain. I created a separate webhelp project, and hid the output in a subdirectory of primary, so it looks like this:
/help/index.htm <primary content, with A/B generated as part of standard webhelp>
help/A/a.htm
a_rhc.htm
a_csh.htm
help/B/b.htm
b_rhc.htm
b_csh.htm
help/foo/index.htm <sneaky folder copied in manually so contents are not searched within parent but are within this folder>
index_rhc.htm
index_csh.htm
Inexplicably, although I built the sneaky project the same way (other than not using content category tags to create subdirs), I have to use index_csh.htm to get the mapIDs to redirect. I don't really comprehend why, if it works ok for the main help project and all the little cshdats etc are created, the old school _rch doesn't work. This is not critical but I'd like to understand in case there is a side effect I've not yet discovered. For that new sneaky folder, I have to use calls like this:
"/help/foo/foo_csh.htm#" + helpID;
The same type of ID (map ID string, not number) are used, so I don't grok the reason.