I guess I'd say both. We were in agreement w/ Hone's statements about checkout, but hamstrung ourselves in regards to a non-JS checkout. I am a little concerned about how the current system will play with the new #ahah stuff in the D6 Forms API when JS is turned off, so having a multi-page checkout in core to fall back on would be ideal.

My goal would be for it to work with the checkout pane system, though this coincides with my desire to redo parts of that system to make such a thing easier. This would be part of my desires for optimization in D6 development.

The quickest way to move here would be for the work to start out as a contrib module, since as the roadmap indicates, I won't be approving any major API changes like this until Ubercart 2.0 (hereafter "Uber Tuber") for D6 is done. However, if we have a good, working contrib that provides an alternate checkout by splitting up the checkout panes and maybe just preserving data from the previous panes in hidden form fields... that would be excellent. It would be much faster to test and then integrate w/ core.

I'm looking for lean code that still maintains a level of flexibility. For example, a non-coder might need to be able to decide which checkout panes to put on which page. We might also need to get pane dependencies in core so users can't screw things up by putting the shipping quote page before the shipping address page. Things like that...

I'd love to hear any thoughts on this or the D6 development roadmap thread.