I added a note on this issue to spec:

NOTE: When migrating a software thread between two harts with
different microarchitectures, the `vstart` value might not be
supported by the new hart microarchitecture. The runtime on the
receiving hart might then have to emulate instruction execution to a
supported vstart element position. Alternatively, migration events
can be constrained to only occur at mutually supported `vstart`
locations.

When migration is triggered by an epoch expiry, the interrupt can be
designed set to only occur between instructions, with vstart=0. But
in general, a software thread could be migrated between harts when it
has been descheduled for another reason, and when vstart might be
whatever the microarch decided (e.g., a device interrupt during a
long-running vector instruction).

I can't see a different solution than that given in the note, which
might limit freedom of designers to not support some vstart values if
they are to be compatible with a profile that supports migration.

Krste