Nitpick: the Sys_argv case should go on line 938 below, where the other non-external primitives are handled.

I don't agree: External and Sys_argv are both compiled to Pccall, which makes it natural to handle them in the same place.
Lines 937-938 are mostly about generic application primitives (plus Lazy_force), so I don't think Sys_argv fits particularly well there.

Actually caml_sys_argv returns a constant directly (it does not raise an exception or allocate), so we could return false here if I understand correctly. In any case, I don't like the proposed code organization because it has no apparent structure (if I add a new primitive, where should it go? There are two groups now). Before there was "External _" and "everything else", this is clear and I think we should follow it. If you have a different structure in mind, there must be a comment that explains what it is.

As I understand it:

• If it calls a C function, it should have an event. This covers External and Sys_argv. The code in lambda_primitive_needs_event_after specifies that if the primitive does not allocate or raise, an event is not needed, but caml_sys_argv is declared with ~alloc:true so for consistency it should get an event.
• If it calls an OCaml function, it should have an event. That is the case for Lazy_force, the various Send primitives, and the Apply primitives.

Basically, I don't agree with your classification of lines 937-938 as "everything else". To me it looks like "everything that calls an arbitrary OCaml function", which is not the case for Sys_argv. If you want to put it in lines 939-943, then fine (this does look like "everything else" to me), although we should probably update the declaration of prim_sys_argv to ~alloc:false for consistency if we do that.

I've pushed a commit which adds a Changes entry and a comment here. I will merge later this week if I don't forget.

I think that this is worse than before because (1) whether a primitive is implemented by a C call or not is not a property of the primitive at the Lambda level, only of the implementation choices further down, (2) this is more work to classify as we have to check if stuff emits a C call or not. But you seem very convinced that this new distinction is a good idea -- it is probably not just your esprit de contradiction at my earlier comment -- and you know the middle-end better than I do... oh well.

Keep in mind that this is not even the Lambda level, this is an intermediary step restricted to Translprim. In terms of Lambda, Sys_argv doesn't exist, we only see a regular Pccall.

Also: the whole point of this function is to decide whether the primitive needs an event or not. The primitive needs an event if it can call arbitrary OCaml code, either directly or by running a GC. So you cannot avoid, at this point, having to know exactly how each primitive is implemented; otherwise you cannot make the right decision.
The conservative decision (for the cases where you're not sure if you need an event or not) is to always add an event. Previously, the only case fitting that was the External case (where we would always add an event, even if the primitive was declared with [@noalloc]). So in a way, this is the right place to put constructors where you do not really want to find out if you need an event or not. All the other cases have clear reasons why they require an event or not, and adding unrelated constructors to them would only make the code more confusing.