I have not looked at the implementation (and will probably not have time before September), but I believe that it would be better if the [@tailcall] annotations in the source (which indicate the user intent to have a tail call at a specific point) were preserved / had priority over this module-level flag.

This is important because [@tailcall] is part of the explicit user reasoning about performance; and it improves the usability of this mode because it lets user write code that is robust to it, when they do rely on non-self tail calls (for example when they use mutually-recursive functions -- which arguably should be handled as self-recursion, or when they use continuation-passing style).

The difficulty is that the flag is implemented in the backend, and that the ap_tailcall attribute is lost in the middle-end (it is lost during the translation from Lambda's Lapply instructions to the application instructions of Closure or Flambda in middle_end.) Implementing this would require tweaking the middle-end and backend to preserve user-provided taillcall attributes.

Also, it would be great to enable/disable tailcall optimization for specific functions.
Something similar to [@@@warning "+/-..."]