The firmware makes no difference here, since what you've found is purely OctoPrint side. The gcode you uploaded had a movement outside the print volume (to -2), so it is warning you. If this is intentional, maybe for a prime line or similar then you can setup a custom bounding box in the OctoPrint settings, under printer profiles.
I'm the author of OctoPrint. No, it doesn't (unless you have some to me unknown third party plugin installed that actively queries information like that from the firmware somehow and then modifies OctoPrint's printer profiles). The only thing that this warning depends on is the information in the printer profile.
My dear friend, your solution is not the solution, I'm sorry.
The problem maybe the gcode if with one fw or the other I have always the same warning but as I stated before, with the same gcode, same printer profile, I have no error with the 2.0.5.3 firmware.
I agree with @Charlie_Powell, to my knowledge as the one who's maintaining the code this cannot technically be the firmware. Still, if you want anyone to take a look at this, you'll need to share the GCODE file in question and a system info bundle with enabled serial.log and ongoing connection during file load from both firmwares, and also the printer profile you use for connecting. Note that if you are using a different printer profile in both cases, that would explain the change in behaviour as well. If you resliced the file, that could also be a reason. Also run in safe mode to be absolutely sure you don't have some third party plugin messing with things.
This all doesn't change though that this particular message -- if you are talking about this one:
is strictly dependent on your printer profile settings. I can't tell you anything else, what you are describing is simply impossible to be caused by a firmware change. The only way you can get this is by loading a GCODE file that has printed areas that exceed the configuration printer profile's bed volume incl. bounding box. There's no query being done against the firmware. There's not even a query being done against OctoPrint's server, the whole evaluation happens strictly on the client that doesn't even know nor care about the firmware.
No. Prompts look completely differently and can't produce a notification like I shared a screenshot of (is this the one you saw or not?). Your printer profile lacks a custom bounding box, as expected. So if your GCODE contains moves outside of the (0,0,0)x(250,220,200) print volume, this warning is working like it should. I can't tell you why you were not seeing it with the old firmware, but that you see it completely fits the so far available data.
Also, as an unrelated issue, your start gcode in Cura is not working right, as these should have their values replaced:
M140 S[first_layer_bed_temperature] ; set bed temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
G28 ; home all without mesh bed level
G29 ; mesh bed leveling/ABL
M104 S[first_layer_temperature] ; set extruder temp
G92 E0.0
G1 Y-2.0 X150 F2400G1 Z3 F720
M109 S[first_layer_temperature] ; wait for extruder temp
That's what I told you several times already. It cannot be the firmware. It's technically completely impossible.
Now... Do you use third party apps to start a print sometimes? A slicer like Cura or PrusaSlicer? Some mobile app? An LCD based client like OctoDash or similar? As I said, the warning gets evaluated and generated completely on the client side. So if you start a print from anything but the included UI, it won't get triggered even with a misconfigured printer profile.
I understand when you say that octoprint non take informational from the fw, but at that time it was the only difference I can see so I'm only reporting the situation.
Now, the printer is directly connected to a eeePc with octoprint installed, no slicer installed on the same eeePc, it is a clean install of Linux Mint,
No slicer used in the same session with the printer
The gcode viewer show the y-2 step but sometimes the warning is triggered, sometimes no.
I will try to report if I noticed when it is not triggered if it can help
Do you reupload the file in question in between tests? The warning can't be triggered if the file hasn't yet been analysed and thus its dimensions aren't known yet. Analysis takes some time after initial upload, then triggers a file list refresh on the client side, then that has to go through before the information is available. If you upload, then select right away, analysis hasn't run yet and the warning only generates on file selection, so it won't generate then either.