Haxe 4 Int-to-Float coercion behaves differently on JS and eval targets after migrating shared numeric code

Context

I maintain a Haxe 4 library that is compiled to both JavaScript (hxnodejs) and the eval target. The codebase relies on implicit conversions between Int and Float in arithmetic and function arguments, and I am trying to decide whether I can keep that style or must normalize everything to explicit conversions.

Uncertainty

The language documentation indicates that implicit numeric conversions are target-dependent: some back-ends insert runtime casts while others reject the same code at compile time. What is not clear to me is where the exact boundary sits for Haxe 4.x — which targets silently coerce, which raise compile errors, and whether the behavior changed between minor releases. I also cannot tell from the docs whether the strictness applies uniformly to function argument passing, return types, and arithmetic expressions, or only to some of these cases.

I would like to keep a single source tree without per-target conditional compilation for numeric code if that is realistically safe.

Questions

1. For Haxe 4.x, which documented targets permit implicit Int↔Float coercion at compile time, and which require explicit casts or Std.int / float conversion?

2. Does the coercion rule differ between arithmetic expressions and typed function signatures on the same target?

3. Is there a compiler flag or typedef pattern that makes numeric conversion behavior consistent across targets without sprinkling #if blocks?