That mod scans and touches all building prototypes. And only with Machine Scaling, this happens:

41.335 Loading mod Will-o-the-Wisps_updated 0.3.13 (data-final-fixes.lua)
41.340 Error ModManager.cpp:1514: Failed to load mod "Will-o-the-Wisps_updated": Will-o-the-Wisps_updated/prototypes/changes.lua:33: attempt to compare number with string
stack traceback:
Will-o-the-Wisps_updated/prototypes/changes.lua:33: in function 'set_corrosion_resistance'
Will-o-the-Wisps_updated/prototypes/changes.lua:46: in function 'set_corrosion_resistance'
Will-o-the-Wisps_updated/data-final-fixes.lua:2: in main chunk

The failing line in that mod is:
elseif preset and proto.max_health and proto.max_health > 0 then

It's most likely because this mod uses MSlib.string_multiply_values to fill max_health but leaves the result as a string. But since https://wiki.factorio.com/Prototype/EntityWithHealth says that the field is float, anyone can assume it to be a float.

I've made a small patch that fixes this problem for me. Makes MSlib.string_multiply_values play nice again with other mods and both unit-marked and unitless data values. Probably not optimal. Won't publish it myself due to the mod license.

Sorry, my bad. It should absolutely be handled as integers. I have done this many times before (and after), like what I have already been doing to many of my other mods.
Only this mod and Schall Pipe Scaling are instead using this string_multiply_values() construct. Cannot not remember why I did this, guess I was too tired when writing this part...

This should be fixed in the new versions 0.17.14 / 0.18.5 / 1.0.0.

Solved: 1.0.0 works for me.