I'm in favor of not breaking existing code, but I believe that only the change in translcore.ml is required to achieve that. (And bootstrapping does not seem required either.)

I agree with Alain.

To clarify: the compatibility breakage I've seen in the wild comes from changing the primitive name of the string-related externals, which are advertised in the interfaces of some libraries that basically include String. So it would be best if the primitives of all functions in the String modules remained %string_... (this means that the present PR has to change them back to what they were before #596), but the primitives of the Bytes module (or bytes_* functions) can be the new %bytes_* primitive -- in theory that may break compatibility as well as recent code could have re-exported this Bytes module with the %string names, but this is recently modified code that will be easy to update, not old code that hasn't been touched and kept working for years.

I don't have opinions here, my current PR will not break any existing code, should we use "%bytes_safe_set" somewhere, like Bytes.ml?

Yes, I think String* modules should use %string_* and Bytes* modules should use %bytes_*. Similarly, bytes_set could use %bytes, as Alain mentions in his code comment.

I think that once this PR lands in 4.04 it would be nice to have a second beta to fish out the remaining issues -- there are already a few fixes in the branch that it would be nice to have users test. I updated Batteries with the post-#596 state (changing all %string_ to %bytes_), and I'm waiting for the resolution of this PR to update again (reverting some of the changes) and make a 4.04-compatible release -- I suspect that extlib may be in the same position, cc: @ygrek.

which are advertised in the interfaces of some libraries that basically include String

Thanks, I see. This could also be addressed by having the compiler normalize %string_safe_set to %bytes_safe_set early enough so as not to break the inclusion check, but I'm also ok with the current solution.

Any opposition to merging this PR in its current state?

Code-wise, I like the current state -- I haven't checked yet that it does restore buildability of affected packages but we can always adjust after the fact. Do we need the bootstrap part?

we need do at least one bootstrap pass, doing once is the same as doing twice. (I did it twice just in case)

I am in favour of this patch, having recently encountered this breakage...

@damiendoligez can we get this into 4.04? Thinking about this, I think that a reviewed version of the -cclib PR should also be part of another beta release.

@gasche let me test this PR. It seems to me that String.create and String.unsafe_set will also cause problems in their current state.

completed and removed the bootstrap, then merged into 4.04 (commit 9b0da03)

Now the wget, rml, and flowcaml packages compile correctly.

(Batteries hasn't had a release with the previous primitive states so there is no compatibility issues with rolling back the changes. If users took the habit of following trunk more closely, some of them would similarly have to roll back on changes we cancel for compatibility reasons.)