I am not sure to get your question correctly. Do you mean, are Constituent2 ids equal to Constituent1 ids?
If so, in the reproducer the answer is no, as all nodes get a fresh UUID as Id.
In my real-life use case, they can because they are not UUIDs and some of the ids assigned to Constituent1 nodes can happen to be equal to some assigned to Constituent2 nodes. But that's neither an enforced rule nor something I am looking for.
If that does not answer your question, please let me know!
Thank you for providing such a thorough bug report. Our Kernel team are actively investigating. It seems that this bug is present on our Record store format but not Block, which is currently available only to Enterprise customers.
I logged a bug report on our GitHub repowhere you may follow along with progress for the fix.
Thank you for the update! I truly appreciate your confirming that this is a bug. I have spent way too long questioning my queries, so knowing that this is indeed not the expected behavior is already half of a fix 
And thank you for filing the issue. I was not sure where to do that, so that's much appreciated as well.
Basically, I'd like to know what indexes an operator is likely to use …
Just to follow up on this: Index usage is shown in the EXPLAIN output when an index operator is planned. However, in your repro you did not have any indexes so a NodeByLabelScan was planned. FWIW the presence or absence of an index on the node lookup is not likely to be related to missed/double reads on the subsequent Expand(All)
Thanks, Alex. Happy Ending!
A fix has been merged and will appear in neo4j 2026.03
Thanks! And thanks to the team for the prompt fix. This is much appreciated!