The link you provided includes a paragraph that explains why it doesn't work:
Note that compound entities (like classes, files and namespaces) can be put into multiple groups, but members (like variable, functions, typedefs and enums) can only be a member of one group (this restriction is in place to avoid ambiguous linking targets in case a member is not documented in the context of its class, namespace or file, but only visible as part of a group).
One approach to consider to solve this problem might be to create different Doxygen projects for each version of your code. You would create a Doxyfile for each version.
In this case, instead of trying to include common code in both sets of documentation using the \ingroup command, you would be excluding unrelated code from each set using conditional sections delimited by either \if...\endif or \cond...\endcond.
So in your version1 module, you would do the following:
/**
* \if _VERSION1_
*/
<all code in your version1 module>
/**
* \endif
*/
and in your version2 module:
/**
* \if _VERSION2_
*/
<all code in your version2 module>
/**
* \endif
*/
Code that needs to appear in both modules, such as your BOOL CLoginFormDlg::OnInitDialog(){} function, would have no such conditional commands, so would be included in both sets of documentation.
In your version1 Doxyfile, add the following line:
ENABLED_SECTIONS = _VERSION1_
and in your version2 Doxyfile:
ENABLED_SECTIONS = _VERSION2_
To link your version1 and version2 documentation sets together, you can use Doxygen's tag file mechanism.
See also