Are you sure the space is unused?
What kind of change- random hex, extra maps, or code added?
0x4FFFF takes you beyond the start on the "map" area on EDC15P. There are many commonly changed maps before that (drivers wish, torque limit, smoke MAF) so surprised for a checksum not to be able to correct that area. WinOLS shows which checksum block is in the current selected area- maybe you could find the checksum for that block and see if it is being corrected for any changes made.

Checksums is an interesting topic though, I'd be interested in being able to disable/control them too.
Would anyone know the best way of going about it?

The registers before calling the checksum subroutine seem to define which area is to be checked. Maybe we could change these values to just keep checking the IROM?
I guess the roughest way would be reversing a jump to just continue with a wrong checksum instead of jumping to reset- would it work?
nops?

Actually there are two checksums on the edc15

When the ecu boots, the IROM checksums the flash in address range 10000-13FFF and then the code in the flash checksums the remaining area. So the checksum as such cant be dosabled entirely cause we can't write to irom( or is this possible on the c167,,, i just need to change one "0x2D" to 0x0D, to disable checksum entirely).

Winols corrects the checksum for 10000-13fff if you make the code addition/changes within winols.. it does not if you import an edited bin

I wrote a simple program to calc checksum for 10000-13fff and disabled the rest of the checksum function...
You could also just copy the checksum funtion from irom to Keil and load the hex file, and see the checksum result and then correct checksum...