Same problem in VS2022. Maybe my 5 cents of info will eventually help uncover the solution. My setup: Two resource DLL projects, different languages (this is probably unimportant). Each project has a main .rc and other .rc's, each with their own resource*.h and string table. All resources are defined in the first project resource*.h files, not necessarily in the very main resource.h of the project. The first main resource.h includes all other resource*.h of the project. This way it doesn't matter where a resource is defined, it will be found at compile time. No resources are defined in the second project resource*.h files. Instead, the second projects's .rc includes the first project's main resoure.h (that in turn includes all other resource*.h of the first project). Not all of these details may be relevant. A use case - how I break it and a possible unsatisfactory solution.
Naturally, the resource ID is unique across both projects.
I was also able to make it compile in the main .rc of the second project by playing with its ID. Also, if it's a true string table duplicate, the error will be different. For example, when I make the ID something that's also used in a string table:
error RC2151: cannot reuse string constants, 4761(0x1299) - "
Like others said, the 299 is probably a group ID which has resources from 298 * 16 = 4768 up to but not including 4784. Interestingly, making the ID 4783 still gives the error with name:299, whereas ID 4784 (new block I presume) compiles fine.
What if the error is generated when IDs that "should" be in the same string table are in different ones? That is, if I move IDs in the range 4768-4783 into one string table... Furthermore, if this setup is limited to one .rc (as moving to a different .rc solves the problem), it should be an easy fix. Will try the update the answer.