"The examples provided use bond orders of 1 and 2 and as the basis of interpolation between their associated parameters."

This sentence is nonsensical. Was some text omitted between "and" and "as the basis"?

What's missing here is jargon for "the x coordinates," like your above "fractional bond order interpolation points." There's also an added "and" that makes is hard to read.

Are XML attributes with the . valid attribute tokens? Would this hold for other serializations, such as YAML, JSON, BSON, etc? I worry this might cause problems.

If not, it would be much easier to specify interpolation points as

k1="820.0*kilocalories_per_mole/angstrom**2" length1="1.45*angstrom" bondorder1="1.0"
k2="1000.0*kilocalories_per_mole/angstrom**2" length2="1.43*angstrom" bondorder2="1.5"
k3="1098*kilocalories_per_mole/angstrom**2" length3="1.35*angstrom" bondorder3="2.0"

If we wanted to maintain backward compatibility, we could use

k_bondorder1="820.0*kilocalories_per_mole/angstrom**2" length_bondorder1="1.45*angstrom" bondorder1="1.0"
k_bondorder2="1000.0*kilocalories_per_mole/angstrom**2" length_bondorder2="1.43*angstrom" bondorder2="1.5"
k_bondorder3="1098*kilocalories_per_mole/angstrom**2" length_bondorder3="1.35*angstrom" bondorder3="2.0"

and have bondorder1 default to 1.0, bondorder2 default to 2.0, etc. for backward compatibility and simplicity.

Great call. I think that the bondorderN solution is exactly what we need here. This sidesteps potential issues with support for . characters in different representations.

If we wanted to maintain backward compatibility

This may not actually be possible at all. The Bonds and ProperTorsions section versions will need to be bumped for this update, since this adds a new keyword (bondorderN) that wasn't in the old section. (that is, if today's version of the OpenFF toolkit says that it supports Bonds section version 0.4, and the bondorderN keyword comes in, then an error will be raised. So the section version must not be 0.4 any more).

We explicitly forbid reading "serendipitously" valid OFFXML contents that have an unsupported version. This is because the version number can change the default values of optional attributes. So two nearly-identical OFFXML files that differ only by a section version could encode different physics.

But REVERSE compatibility isn't really a problem, because non-time travelers will be more interested in FORWARD compatibility. The current parameter handlers can recognize and handle a range of old section versions so we should be in good shape there. (that is, ProperTorsionHandler can be updated to read every ProperTorsions section version from 0.3 to 0.5)

So, this would lead to a spec bump of Bonds and ProperTorsions to version 0.5. I've made an Issue tag to indicate that this will require a section version bump.

have bondorder1 default to 1.0, bondorder2 default to 2.0, etc

I (begrudgingly) think this is a good idea. It's (begrudging) because implementing optional attributes is always a nightmare, especially when they relate to other optional attributes, and double especially for the forest of indexed, double indexed, and optional attributes that ProperTorsionHandler has to process correctly. But I think it's worth it for the user experience, and to have ProperTorsion elements in the OFFXML have a shorter line length.

I think the criticisms above are spot-on and the solution here seems like the best way to approach this. I'll work to update the proposal accordingly.

The only bit of context I'd like to add is that we haven't released any force fields with parameter interpolation, so it's possible this could be coordinated to avoid the need to shop an up-converter of existing files from 0.3 or 0.4 to 0.5. There would be a burden on internal users to update, but we that's easier to do than tweak data that's already slipped out to production.

Including the example from the OFF-EP here would be helpful.

Great call. I think that the bondorderN solution is exactly what we need here. This sidesteps potential issues with support for . characters in different representations.

If we wanted to maintain backward compatibility

This may not actually be possible at all. The Bonds and ProperTorsions section versions will need to be bumped for this update, since this adds a new keyword (bondorderN) that wasn't in the old section. (that is, if today's version of the OpenFF toolkit says that it supports Bonds section version 0.4, and the bondorderN keyword comes in, then an error will be raised. So the section version must not be 0.4 any more).

We explicitly forbid reading "serendipitously" valid OFFXML contents that have an unsupported version. This is because the version number can change the default values of optional attributes. So two nearly-identical OFFXML files that differ only by a section version could encode different physics.

But REVERSE compatibility isn't really a problem, because non-time travelers will be more interested in FORWARD compatibility. The current parameter handlers can recognize and handle a range of old section versions so we should be in good shape there. (that is, ProperTorsionHandler can be updated to read every ProperTorsions section version from 0.3 to 0.5)

So, this would lead to a spec bump of Bonds and ProperTorsions to version 0.5. I've made an Issue tag to indicate that this will require a section version bump.

have bondorder1 default to 1.0, bondorder2 default to 2.0, etc

I (begrudgingly) think this is a good idea. It's (begrudging) because implementing optional attributes is always a nightmare, especially when they relate to other optional attributes, and double especially for the forest of indexed, double indexed, and optional attributes that ProperTorsionHandler has to process correctly. But I think it's worth it for the user experience, and to have ProperTorsion elements in the OFFXML have a shorter line length.