I hate to keep raining on the persistent dream of K-P in groff, but it fits poorly with troff's basic typesetting model. How will it deal with line-length changes that pop up in the middle of a paragraph, due to requests that can come inline or from a macro, perhaps triggered by a trap? K-P faces no such problem; it knows in advance the shape of the region to be filled with text.
The only obviously sure-fire way I have thought of to cope with all the daunting scenarios is to fork a groff copy for each trial breakpoint, run them in parallel, and pick the best at paragraph's end--elegant, but probably slow by a significant factor. A perhaps pracitcal adaptation would be to fall back on parallel evaluation only upon encountering changes of state other than certain routine per-word updates of horizontal and vertical position. I also cite fmt(1) as a cautionary tale. It does notably worse than nroff on unjustfied text. Each paragraph ends up with roughly equalized lines, but evey paragraph gets its own apparent width--a highly visible phenonomenon. K-P is more sophisticated, but I suspect it exhibits the same symptom. Doug
