Prevent accidental proc overwriting, proc signature overloads

Empieza leyendo las dos propuestas y la discusión sobre la semántica de final, overwritable y overwrites. El issue no especifica archivos, pruebas ni puntos de entrada, y la finalización depende de decidir el comportamiento de las palabras clave, evaluar la coincidencia de firmas y realizar investigación de usuarios o telemetría antes de la implementación.

A discussion came up about being able to overwrite procs. There are definitely good use cases for being able to overwrite procs, but the discussion was that perhaps this is not a good thing by default/generally.

A number of proposals were offered, summarized here. For clarity, the term "final" is taken to mean that a proc cannot be overwritten, whether or not there is a keyword final involved.

1. No change in existing behavior, but a new keyword final is introduced, and when applied to procs, prevents them from being overwritten elsewhere.

• Pros: No user code has to change. The implementation is simpler, and doesn't require a phase in period.
• Cons: If a user is accidentally overwriting a proc when they didn't mean to, this feature will not benefit them.

2. Add overwrites/overwritable/overwrite keyword(s). This changes existing behavior, so that all procs are final by default, but procs that are marked with some combination of either/both overwrites and/or overwritable are allowed to be overwritten.

• Pros: It's impossible for users to miss accidental overwrites, as this is much stricter.
• Cons: Behavior change, requires users to change code and requires a phase in period. It seems unlikely that this would be a widespread problem, but in general this would require a phase in period, and we should create telemetry on this to count how many people are affected, and the magnitude that they are affected before making this functionality visible to users at all.

For option 2, there is still a need to determine the specific keywords that are used. Do you put the overwritable keyword on the "master" proc, and the overwrites keyword on the sub-proc? Or do you just have a single keyword overwrite which you tag on all procs that are intended on being overwritten and the procs that overwrite them? This is a minor discussion that needs to happen still, but does not materially change the overall decision.

Another discussion is to also perform signature matching on non-final procs. So redefining a proc (which is either implicitly or explicitly overwritable) with a new signature should be disallowed. I generally support this, but this is a different decision and implementation. This may however prevent valid use case, so further user research needs to be done to provide input to this decision.