jarrostick ... the solution suggested by your 3rd paragraph is fine and will add additional visibility to the redirection step through the reports and viewflow.
you are correct, both the standard worklist web part and k2 workspace worklist do not allow you to easily extend the UI to include an additional comments screen, but there are still other options.
1. create your own worklist with additional functionality.
you might be surprised to hear how many customers do this, especially in cases where worklists must manage high volumes of data, like 10,000+ worklist items per day, up to many times that, in fact, among a user population of 50 people or more. the worklists we provide out of the box do not lend themselves to handling that kind of data easily, so some of our customers will create a filtered hierarchical view of a group's worklist, for example. there are other possibilities here but the point is that creating your own worklist opens up many options.
2. explicitly change the flow to allow for redirection with comments.
you hinted at this in your 3rd paragraph but it sounds like you're specifically suggesting that you use the same activity and make the destination users dynamic. that's certainly one option. the other is to create new activities to represent a redirection. it depends on your case and how you're using the platform. it also depends on what you want to see in your reports. so, this option covers your suggestion and others that require changes to the flow itself.
3. modify activities requiring support for redirection with comments
in this case i'm trying to cover your suggestion in paragraph 3 of your post. you can use code, or alternatively you can use rules for destination sets. if you haven't used these kinds of rules before, you can get to them by modifying the destination rule of any activity, clicking the wizard's back button, then checking advanced. any one of the first 3 options for assigning work, "all at once" , "serial" or "parallel" will all work here, click "next" to setup slot dynamics, then one more "next" to get to the rules for destination sets. here you can define a destination set as a named group of destination users, groups, roles, etc. and then wrap the set in boolean equation based on your process data. in this case then, your suggestion for paragraph 3 would end up modifying infopath form data which would be tested by the rules for destination sets to decide on who would be involved in the activity.
hope that helps.
