Smart Date field shows incorrect values in form after previewing node

Problem/Motivation

After previewing a node with a smart date field that contains multiple recurrences and then going back to edit the node via the "Back to content editing link", the values in the smart date fields are not the same as they were entered prior to previewing the node. The Add Another functionality seems broken as well after coming back to the form.

Steps to reproduce

1. Go to a node type that contains a Smart Date field with recurrence and has Preview enabled.
2. In the Smart Date field, add three recurrences: the first repeats at an interval; the second is a single instance, doesn't repeat; the third repeats at an interval. I don't believe the number of repeating occurrences matters, but make sure it's at least 5 for good measure.
3. Preview the node.
4. Click on the "Back to content editing link".
5. Notice that the Smart Date field does not contain the same values as it did prior to preview.
6. Click Add Another on the Smart Date field. Notice that it doesn't work as expected.

Proposed resolution

The field should contain the same values before and after preview, and the Add Another functionality should continue to work.

I'm not familiar with the Smart Date code, but in case it's helpful in finding a solution, here's what I found when debugging. I was able to make the problem better with a few tweaks, but wasn't able to fully resolve it.

Within SmartDateWidgetBase::formMultipleElements, the $max variable calculated at the beginning of the function was much lower when looking at a Preview form than viewing the same values in an Edit form. I changed this to use count($field_state['original_deltas']), which was the same as the value being used in Edit, and this seemed to solve some of the issue.

I believe the other source of strangeness is coming from how $element items are indexed within the $elements array in the same function (SmartDateWidgetBase::formMultipleElements). The element keys are based on where the element falls in the list of all occurrences. So instead of [0 => , 1 => , ...], it's [0 => , 7 => , ...] (when there are 7 recurrences within the first recurrence rule). This clashes with an assumption down the line in Core that expects these element keys to be consecutive integers starting at 0 when populating them with user input.

Again, I'm not super familiar with most of this code - Smart Date and Core form builder logic - so feel free to disregard my findings if they're way off base.

Remaining tasks

User interface changes

API changes

Data model changes