Currently beacon-nodes use the eth namespace to read state and event-logs, to track beacon-chain deposits (see deposit contract consensus specs), as well as "eth1-data-votes" (legacy, but this voting process will still be present in the merge, until later cleanup fork).

During the merge-interop event I think @holiman (iirc?) proposed to expose the eth namespace under this same new secured engine-specific port, so beacon-nodes do not have to open two different connections to the same execution node.

All execution-layer clients already support these namespaces as "modules" of some kind, and this modularity means the eth namespace can be exposed on this endpoint with minimal changes in the EL, and reduces changes on the CL (would otherwise need to support two different connections for engine and deposits work).

Assuming this reduction in setup complexity/work is desired, I am not sure if it should be a MAY or MUST in the spec. Is there any case where we do not like to expose eth under this endpoint?