(Note: Given where we are in the EF6 release I am filing this directly for a future release as discussed today after triage):
There are scenarios in which some provider or custom implementation of a pluggable EF service could take advantage of registering its own interception events and possibly include them the log output. One example of this would be an execution strategy that wants to log retry details together with the rest of the logged information. Currently interception and logging are limited to the event interfaces built-in EF, but we could change it in the future to make it more extensible. In a sense this is similar to how custom migration operations work: a new operation is defined, and the SQL generator on the other end of the pipe is extended to handle the new operation.
There are scenarios in which some provider or custom implementation of a pluggable EF service could take advantage of registering its own interception events and possibly include them the log output. One example of this would be an execution strategy that wants to log retry details together with the rest of the logged information. Currently interception and logging are limited to the event interfaces built-in EF, but we could change it in the future to make it more extensible. In a sense this is similar to how custom migration operations work: a new operation is defined, and the SQL generator on the other end of the pipe is extended to handle the new operation.