It would be great to see a list of known&#x2F;anticipated compatibility issues. For example, I notice that when compiling `String.set` with OCamlScript, the generated JS ends up trying to set&#x2F;mutate a character in the JS string, which has no effect because JS strings are immutable. (I&#x27;ll file a github issue). I imagine there will be several small issues like this and it would be good to get a sense for how much work it would be to solve that long tail of compatibility work. In the process, I think the community can help determine if this approach could ever practically match the near-perfect level of compatibility that js_of_ocaml has achieved via byte code compilation - and whether or not it matters. To me, compatibility is very important, but so is debugability. It might be clear that it&#x27;s okay to compromise the readability of OcamlScript in order to achieve more compatibility without compromising debugability (for example, using a `new MLString(&quot;xyz&quot;)` wrapper that uses a JS `String` by default for performance, but then swaps it out upon any mutation. (Or perhaps you can limit it to programs that have disabled string mutations in later versions of OCaml).<p>The good news is that <i>if</i> you can achieve perfect compatibility with this approach, then I believe that runtime performance becomes less of a concern and OCamlScript&#x27;s job gets a lot easier. This is because, if you&#x27;ve achieved perfect compatibility, you can easily compile your project with another toolchain such as js_of_ocaml, that has equal compatibility, but (in this hypothetical scenario) had chosen to focus more on performance instead of debugability - without changing anything in your program.<p>This would free you up to not have to worry about applying any optimizations in this readable&#x2F;debuggable mode - you get to focus entirely on whatever makes the development flow faster&#x2F;easier. (You&#x27;d probably still want tail call optimization because order of memory usage could be considered a key part of compatibility).<p>Similarly, I wonder if the existence of a fully compatible, (hypothetically) slow runtime performance, but perfectly debugable compiler backend, would then free up js_of_ocaml from some of the constraints&#x2F;work that is required to make their code output reasonably simple&#x2F;debuggable. Does the existence of a fully compatible OCamlScript mean that js_of_ocaml&#x27;s job gets easier?<p>I&#x27;m excited to discuss how the two projects could potentially become an asset to each other.<p>edit: I started a discussion on Github here: <a href="https:&#x2F;&#x2F;github.com&#x2F;bloomberg&#x2F;ocamlscript&#x2F;issues&#x2F;12" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bloomberg&#x2F;ocamlscript&#x2F;issues&#x2F;12</a>