#931 Inconsistent SDF conversion behaviour between 2.3.0 and >=2.3.1 ?

[schymane]

Trying to strip properties from an SDF, we've come across a change in behaviour between Open Babel 2.3.0 and 2.3.1/2.3.2 where Babel >2.3.1 seems not to read or output the valences correctly and results in output SDFs with many radical atoms defined. Deleting or adding Hs has no effect, if we output SMILES then the SMILES also contain atoms with non-standard valences, e.g. converting babel -isdf my_sdf.sdf -osdf my_new_sdf.sdf returns an SDF with
M RAD 8 7 3 8 2 9 2 10 2 11 2 12 2 13 2 14 2
The corresponding SMILES:
O=C1N(C=NC=NC1)C2=CC=CC=C2 (from the SDF properties)
O=C1N(c2[c][c][c][c][c]2)[C]=N[C]=N[C]1 (from Babel GUI)
So, we have tested this on:
Linux, Mac 2.3.0 - we obtain a SDF / SMILES with the molecule we expect
Windows GUI or command line 2.3.1, 2.3.2, Mac - we obtain the radical representation, i.e. SDF with M RAD lines for each molecules and smiles with [c] and similar as above. The SMILES via Windows GUI did change slightly between 2.3.1 (O=C1N(c2ccccc2)[C]=N[C]=N[C]1) and 2.3.2 (O=C1N(c2[c][c][c][c][c]2)[C]=N[C]=N[C]1), but the M RAD line in the SDF was the same.
The input SDF (attached) was generated via MetFrag command line using the CDK to output structures retrieved from ChemSpider. A difference in the SDF is that the 6th column after the atom letter in the input SDF contains the valences, this is not in the output SDF from Babel - for 2.3.0 or >=2.3.1.
I am not 100 % sure if this a problem with our SDF, or a bug? If the former, please let us know!