Although it is accurate to say that current_step_id should match the current step, I think perhaps there is some misunderstanding about default values.

Default values will never overwrite an existing/submitted value.

For example, when you load the starting form, the field is blank so it would populate with the step id value as a default (probably where the 14 originates).

When you load the user task, that field already has a value, so it's not that current_step_id is wrong; it is not being applied because the field already has a value from the previous submission (i.e., default only fills empty fields).

This is all expected behavior.

One option would be to use workflow; you could have it run a workflow service task that uses the Set Business Process Variables activity to set that field back to NULL and then the default should be applied in the next user task.

You could use a different field/variable for the second task.

Another way to handle this would be to use a hidden "helper" field.

Instead of using the default directly in the display field, add a new field with the step values as the defaults. Then, add field rules to Hide Always and Ignore the value so it doesn't get saved.

Next, instead of using the default, use a calculation to set the display field equal to the hidden source field.

Because the hidden field is ignored, it will update to the correct step id on the next task, so at that point all you need to do is trigger the calculation to run.

Adding CSS class to source field for easy identification

Calculation on display field

Field rule for source field

Quick-and-dirty javascript example to trigger the calculation to refresh based on the configuration above.

$(document).ready(function(){
    // trigger calculation after form load
    setTimeout(function (){
      $('.stepIdSource input').change();
    }, 100);
});