In rdkit, how to preserve stereochemistry in a SMARTS subgraph? In rdkit, when doing a MCS search for molecules bearing a chirality center, (how) is it possible to preserve the stereochemical information when exporting the subgraph to a SMARTS string?

Consider the following three molecules:

&gt;&gt;&gt; mol_ccw = Chem.MolFromSmiles('C1=C[C@H](Cl)CCC1')
&gt;&gt;&gt; mol_cw  = Chem.MolFromSmiles('C1=C[C@@H](Cl)CCC1')
&gt;&gt;&gt; mol_lin = Chem.MolFromSmiles('C=C[C@H](Cl)CCC')


Doing a chirality-sensitive subgraph search leads to the somewhat expected result:

&gt;&gt;&gt; rdFMCS.FindMCS([mol_ccw, mol_cw], matchChiralTag=True).smartsString
'[#6](=[#6])-[#6]-[#6]-[#6]-[#6]-[#17]'
&gt;&gt;&gt; rdFMCS.FindMCS([mol_ccw, mol_lin], matchChiralTag=True).smartsString
'[#6]=[#6]-[#6](-[#17])-[#6]-[#6]-[#6]'
&gt;&gt;&gt; rdFMCS.FindMCS([mol_cw, mol_lin], matchChiralTag=True).smartsString
'[#6]-[#6]-[#6]-[#6]-[#6]'


The subgraph over mol_cw and mol_lin includes the stereocenter. But unfortunately, the chirality information is not stored in the SMARTS string, and using [#6]=[#6]-[#6](-[#17])-[#6]-[#6]-[#6] for a chirality-sensitive substructure match leads to the expected result of the pattern made from that SMARTS string matching all three molecules:

&gt;&gt;&gt; patt = Chem.MolFromSmarts('[#6]=[#6]-[#6](-[#17])-[#6]-[#6]-[#6]')
&gt;&gt;&gt; len({mol_cw, mol_ccw, mol_lin}.GetSubstructMatches(patt, useChirality=True))
1


Manually inserting a lazy @H or a &amp;*&amp;H1 at the stereocenter leads -of course- to the desired result:

&gt;&gt;&gt; patt = Chem.MolFromSmarts('[#6]=[#6]-[#6@H](-[#17])-[#6]-[#6]-[#6]')
&gt;&gt;&gt; len({mol_ccw, mol_lin}.GetSubstructMatches(patt, useChirality=True))
1
&gt;&gt;&gt; len(mol_cw.GetSubstructMatches(patt, useChirality=True))
0


Now, when matching mol_ccw and mol_lin, how do I get the stereochemistry-aware SMARTS string [#6]=[#6]-[#6&amp;*&amp;H1](-[#17])-[#6]-[#6]-[#6] as the substructure in the first place?
For anyone interested in this topic: I just learned that this is a bug that should already be filed on GitHub, but apparently the developers themselves do not find it anymore - probably that's why I didn't find it. Nonetheless, the bug is known and will be fixed in the next release.