Please add to the list below anything that is missing. Also please correct anything that's wrong, I'm working off the top of my head now. A first incomplete start:

• KDE 3 apps using DCOP expect a DCOP server using a given binary protocol. The KDE 3 DCOP server is found using ~/.DCOPserver_$hostname_$display, and uses the ICE protocol for authentication. KDE 4 will need a DCOP server that has the same semantics, or a compatibility replacement. Are there problems to be expected here, or will this stay in a way that's KDE 3 compatible?
• KDE 3 apps expect a ksycoca using a specific binary layout. ksycoca is designed to be upwards compatible within KDE versions, but not necessarily to survive major upgrades to e.g. internal representations of variables. Are there problems to be expected here wrt Qt 3/4 ?
• $KDEHOME and $KDEDIRS have a defined meanign that will have to be preserved
• $KDEDIR is scheduled for removal since KDE 2, and KDE 2 and KDE 3 both also support $KDEDIRS, so this is a special case that we can remove now after 5 years of extended support.
• Kiosk profiles are governed through /etc/kde3rc under SuSE, but not for a vanilla KDE, where it is just /etc/kderc. The profiles themselves default to /etc/kde-profile and /etc/kde-user-profile. Potential problems arise in overlapping config files (kdeglobals for KDE 3 and 4), so KDE 4 will need a more future-proof naming scheme.
• KDE libraries have to coexist alongside. That can be handled by just setting $PREFIX accordingly though, AFAICS
• kdeinit and notably kded need precautions to work with older binaries. (Which? What are the usage patterns?)
• DCOP interfaces will need to remain compatible or provide compatibility wrappers, at least for the major applications.
• kdialog will need to stay syntax compatible.

There's the problem of Qt's datastream changing internally, but we have already solved that in the KDE4 port by explicitly setting the stream version. QDataStream and all the classes support backwards-compatible marshalling since Qt 1.x, so it is quite easy.

Yep,and I've tested this to some extent early in the port (e.g. talking to KDE3 apps using a KDE4 dcop command), but not extensively. A problem is that tons of code marshalls manually, so there need to be zillions of setVersion calls (or better, the code needs to be converted to use DCOPRef). Some of the marshalling is quite sloppy, too, though.

KBuildSycoca situation is similar: with setVersion calls in place, last I checked it could open my 3.x ksycoca file. And of course ksycoca itself is designed to be expandable in a backwards compatible way, with version numbers and everything.

But from the ideas we got last time we discussed D-BUS here, I'd say that it is feasible to give full access to the new environment, not just a compatibility area. In other words, I think the conclusion was:

• KDE4 apps will speak D-BUS natively
• KDE3 apps can talk to KDE4 apps normally, and vice-versa
• KDE3 apps cannot talk to non-KDE D-BUS apps
• non-KDE D-BUS apps can send simple messages that are to be relayed into DCOP

This would, of course, require that we have a dcopserver. In fact, if we want to support DCOP at all, we'll need dcopserver.