I am wondering if it is possible to handle problems where a boundary constraint is dependent on a parameter that can be changed by the optimizer.
Absolutely.
So the mass of your vehicle is:
Initial mass = Stage 1 Prop mass + Stage 1 Dry Mass + Stage 2 Prop Mass + Stage 2 Dry Mass
If you have a state or ODE output that tracks your current vehicle mass (m). Before the stage 1 drop, m_1 will include the stage 1 dry mass. Immediately after the drop, the total mass m_2 will not.
At that point, the equation which defines the relationship will be:
m_1 - m_2 = m_stage_1
As you said, you cannot specify an ODE variable as the bounds in a boundary or linkage constraint (they're just numeric values), but we can write the equation above as a linkage constraint.
If you make an output in your ODE that is "current total mass minus stage 1 dry mass" (m_minus_stage_1 for lack of a better name), then we can make that variable continuous with the current total mass at the start of the next phase after the drop.
traj.add_linkage_constraint(phase_a='phase1', phase_b='phase2',
loc_a='final', loc_b='initial',
var_a='m_minus_stage_1', var_b='m',
equals=0)
Also, there's nothing stopping you from using an openMDAO constraint to link them here. Something like this would work.
prob.add_subsystem('mass_linkage', om.ExecComp(m_error = m_1 - m_2 - m_stage_1))
prob.model.connect('traj.phase1.timeseries.states:m', 'mass_linkage.m_1', src_indices=[-1])
prob.model.connect('traj.phase2.timeseries.states:m', 'mass_linkage.m_2', src_indices=[0])
prob.model.promotes('traj', inputs=[('parameters:m_stage_1', 'm_stage_1')])
prob.model.promotes('mass_linkage', inputs=['m_stage_1'])
prob.model.add_constraint('mass_linkage.m_error', equals=0)
Note that parameters are treated as inputs in Dymos, and OpenMDAO doesn't allow an input to connect to another input. They both must be promoted to the same name. We're working on a 'statics' output component in Dymos that will let us output those parameters so they can be connected.
Now I fully admit that the manual way, while more efficient than calculating something in the ODE, is more confusing. That's the sort of complexity that dymos is intended to help users deal with.
Also, there's probably a way to handle this as a set of boundary constraints as well, but it seems like it's more naturally posed as a linkage constraint.