Problem(s) with variable timestep sizes in the Gizmo scheme

While working on the moving mesh hydro scheme and comparing it with what is present in the hydro scheme, I came across the following issues.

The way in which the gravitational acceleration is accounted for does not seem to work with variable timesteps. Specifically, if a particle is drifted more than once in its timestep, it will receive an incorrect gravitational acceleration. The problem is that in the gizmo scheme (like the moving mesh scheme) a particle has a fluid velocity and a particle velocity. During the drift, the particle velocity is kicked using the gravitational acceleration. We then need to apply the same kick to the fluid velocity. This is done in Gizmo in the hydro_predict_extra function by adding the difference between the kicked particle velocity and xp.v_full to the fluid velocity. This works fine if all particles have the same timestep, but is incorrect if a particle has a larger timestep than nearby particles and is therefore drifted twice or more during it's timestep. Any additional drifts will apply a kick to the fluid velocity that is too large, since the particle velocity has been kicked multiple times, but the xp.v_full has not changed.

To illustrate this I tested the following setup: a homogeneous box in a constant downward gravitational field of size 1, but with 4 times more particles in the upper half (which causes the timesteps of the upper particles to be smaller than the timesteps in the lower half). After a time x, all the particles should have downward velocity of x. Below are the results for gizmo-mfv compared with shadowswift after a time t=0.1 and t=1. As you can see, there are large deviations in the velocities around the border between the low resolution and high resolution halves with gizmo. ShadowSWIFT does reproduce the correct velocities.

A second issue I came across is that the way the flux.dt is set in gizmo differs from the way I do it in ShadowSWIFT and the resulting timesteps are actually different when the timestep limiter is applied. I am not entirely sure yet which of the two ways is correct and I also have not managed to find a scenario in which this seems to have a meaningful impact on the results...