Usually these kind of systems take localizer time rate data into account when providing command steering. I believe BMS is simply comparing heading and localizer deviation to course. E.g. when loc deviation is zero then it’s making command heading equal to localizer course. That’s obviously not the best command when crosswind is present. What you’re getting is a balance of factors where you’re getting a constant deviation solution not at zero deviation. You’re downwind which is providing some upwind steering command but not enough to get back to loc center, just enough to settle in a constant downwind loc position. If you were in a position of more deviation steering would act to reduce deviation but if you were more central steering would be to increase deviation.
In this kind of system normally the steering command is proportional to deviation, integrated deviation over time, and possibly derivative of deviation. That’s your classic PID controller where P is the simplistic “if left go right”, I is the integration “we’re still not getting there, go right harder”, and D is the “we’re getting there too fast, go right weaker.” Practically the command steering cue position should not overlay on the FPM unless two conditions are met: localizer deviation is zero and localizer deviation rate is zero.
Honestly it looks like this is coded based on heading and not on track. I can’t imagine how this would happen in a track-based calculation. A function of deviation and deviation rate spits out a correction. If correcting to the right steering cue moves right of FPM. Pilot flies a new track, values change. One thing that usually goes with these systems is a gain factor based on proximity to the localizer or the sensitivity keeps increasing as you get closer which can be bad. Sometimes it’s a timer after joining glideslope or radar altimeter, neither is flawless but they’re better than nothing.