Thank you for your thoughts @randomishwalk ! After a few conversations at Devcon about this proposal, here are a few answers.
On the goals, I am not sure whether there is an impossibility theorem, but there are definitely dependencies between points 1 to 5. If you assume that the dominant builder is censoring, and if you assume that a proposer shuts themselves out of receiving a block made by a dominant builder whenever they mandate the inclusion of some transaction (either via inclusion-list, partial block building or PEPC pre-commitment), then there is absolutely a trade-off between value accrual and censorship resistance. It may be mitigated by the fact that over time, censoring builders are shut out of making blocks for non-censoring proposers, and hopefully their edge diminishes as a result (e.g., the private order flow they may control decides that the greater latency is not worth it, and connects with different builders). It would be great to formalise these points better, I hope to publish something on the cost of censorship soon but the models are tricky!
Protocol complexity is an interesting one too. h/t to conversations with sxysun on expressivity, though I might do a poor job at relating his ideas, so take the following as my own interpretation which is possibly not in line with what he has in mind. But anyways, there is a space of mechanisms that attempts to maximize social welfare by satisfying user preferences. The space of user preferences over state is hugely complex, not only because state is derived from a general state machine, but also because preferences may be in conflict with one another. Given this assessment, how might we attempt to maximize social welfare? We need mechanisms to mediate user preferences, and the more expressive mechanisms are, the better hope we have to make an allocation that maximizes welfare. Then there is perhaps a trade-off to make: the less expressive the mechanism on the protocol-side (e.g., the whole block auction), the more expressive the mechanisms need to be on the user/searcher/builder-side, to aggregate preferences up to making a single PBS bid (see also my talk at Devcon). PEPC is an attempt to increase expressivity on the protocol-side, under the assumption that there may be some value that cannot be realised otherwise. This assumption needs to be analysed further to understand whether that is indeed the case.
I believe there are two independent constructions of interest in the post. The first is the protocol infrastructure for Eigenlayer-type restaking. We might decide not to do PEPC or something akin to it, but we might still think it’s a good idea to have protocol facilities for the principal-agent problem (PAP) of Eigenlayer, e.g., ability of an outside smart contract to update the validator’s state on the CL. Of course, even with such protocol features it would be always possible for an Eigenlayer-type system to let a validator restake and not bother surfacing updates to the CL, then it would probably be more of a social consensus scenario where we frown upon restaking services that don’t surface the signal clearly enough (I believe Eigenlayer addresses this by providing exhaustive monitoring).
The second result is PEPC. In-protocol PBS in general is an attempt to resolve the PAP coming from dependencies between the validator (the principal) and third-parties (the agents). PEPC is an attempt to generalise a solution to the PAP. h/t to a chat with @adompeldorius who described it as “using the coordination mechanism feature of Ethereum to coordinate proposers themselves” (again, my own words, hopefully not a misinterpretation 
)
Imo the optimistic approach won’t cut it for a protocol-side feature, we want much more guarantees than this, so the pessimistic approach would be the way to go. Note however that it doesn’t rely on validity proofs (SNARKs), I was only making the point that validity proofs could be used to simplify verification of the commitments. It’s a big open question what the space of these commitments are, how flexible we want them to be etc. But note also that it doesn’t purport to fully replace out-of-protocol restaking services, which could offer validators to enter into much more general commitments, which cannot be verified in-protocol (e.g., EigenDA?)
Then the data availability problem has more to do with the delivery of the specific commitment by the third-party, at which point the protocol needs to decide what has been delivered and what has not been delivered. It’s not as bad as data availability as understood e.g., with rollups publishing data to L1 etc.
Agreed! I definitely want to see more research on this. Maybe the whole block auction with inclusion lists satisfies it. Maybe it’s good enough for the exec-block PAP, but we want something more generic for other things (witnesses, validity proofs, etc.)
I am not sure. What I would like to work on is a proof-of-concept of e.g., the PBS whole block auction end-to-end under the PEPC framework, then adding inclusion-lists, then maybe even “mev-geth” (parallel bundle commitments) and building up a richer library of commitments. I think it will become clearer what’s needed and at what stage which EIPs become relevant.
I strongly feel AA is an important part of flexible user-side commitments, I don’t think it’s particularly controversial, I am also probably late to recognise it since I didn’t look too deeply into AA yet 
But I am wondering if PEPC could be helpful to mediate the relayer entity in 4337, again as another instantiation of the PAP.
Replied to this one above, I can see a few different ways to go about it, I don’t have a strong opinion until I understand better what each mechanism can provide.
I would be happy first with pen-and-paper proof-of-concepts, then possibly looking at implementation/prototypes.