No we don't duplicate. In fact we can't as those methods would have the same requestmapping signature.
Our current design has one abstract shared parent, ProposalControllerBase for instance. This base provides shared functionality that isn't mapping in SpringMVC. Things like general services and generic methods, like preSave that all controllers in Proposal are likely to utilize. Below that we have the actual controllers with mappings.
We are likely going to create a ProposalGenericController(name?) that will contain the mapped methods that are generic. Things like the generic save and back buttons, generic navigation, refresh etc. Then each page that needs special functionality will have its own controller, like ProposalPersonnelController. This will contain things specific to this page. Methods for adding personnel through the wizard, a special case navigation method for navigating to the personnel page, etc. If we have a situation where it makes sense we might create another level. Where an abstract ProposalPersonnelControllerBase contains unmapped shared functionality and child controllers below that with specific functions for adding personnel and credit split for instance. And we will likely have ProposalWorkflowController for specific approval methods that may not even need to inherit from the ProposalControllerBase as it is unlikely to share any functionality with it or any of the other controllers.
The only alternative I've heard related to providing some kind of controller flexibility is to have each page use a separate mapping. And while this may solve it, we will end up in a situation similar to struts where functionality for each page has to be shared across controllers, particularly functionality related to navigating from one page to another has to be placed in a shared common parent so all pages use the same functionality when navigating to a specific page. A model I never liked and often causes confusion when attempting to explain in-document navigation to people.
As far as the refactoring being asked for, it relates to the 'createInitialForm' and 'initForm' methods. 'createInitialForm' is a protected method intended to be overridden by non-abstract controllers. In a delegation model this obviously doesn't work as easily. So to get our delegation model to work we've had to copy the functionality in initForm and provide a separate method that takes a form in instead of calling a shared method.
While I understand there is more boilerplate code involved in the delegation model and some maintenance required to keep up to date with changes, the flexibility provided far outweighs the downsides for KC. Our large documents never fit easily into the inheritance model used in the KNS and there are a fair number of ugly workarounds in KC to make it work.