>>> I am not sure of the role of Work Packets in the subject pattern....
Design decisions range from very high level to very low. Your question can be thought of as "an attempt to blend two levels of questions into the same level.
The pattern "Collaborative Work Packets (3)" assures that the design decisions around what information is shared between two "Concurrent Threads of Execution(1)" is made early in the design of Caterpillar's Fate style of program design.
Some of my clients have included a client-server technology into their designs -- sometimes because it is popular, not because it made design sense. Client-server is often a technology that firms have little experience with. They have read the trade journals and know it is "hot" but not much else. Their wisdom is quite low around the design decisions of what they can do with client-server, what they should do, and what they should avoid.
The "Collaborative Work Packets (3)" pattern assures that the questions of what is to be passed between concurrent threads is clear early in the design. With answers to all the work packet patterns, we can knowledgeably shop for the appropriate client-server technology, or realize that an alternative makes more sense.
>>> Should Work Packets be viewed as kinds of Informational Object that are passed between Decision Maker Role objects (e.g., between the DMR object(s) for the producer thread and the DMR object(s) for the consumer thread)?
These Work Packets could be implemented as "Informational Role(14)" objects, but that is only one of a number of design choices. As I mentioned earlier, a client-server technology might be a solution. This e-mail response is a kind of Work Packet shared between the Concurrent Thread on your machine and the one on mine. Shared information between two applications running on a Macintosh or Windows 95 each have their own implementations.
The Caterpillar's Fate pattern language strives to raise the appropriate design questions at the appropriate time. The users of the language, can decide what design answer is correct.
>>> In a system with multiple concurrent threads, it appears that one would have a (set of) object(s) at a high level called Decision Maker Role objects for each thread.
Each "Concurrent Threads of Execution(1)" contains one " Systems Citizen Role(10)" object. This object is likely to refer to many "Decision Makers Role(11)" objects. It is the responsibility of the decision maker objects to orchestrate the response to stimuli that may cause a work packet to be passed. "Workers Role(12)" objects such as a buffer might manage the work packets, and an "Interface Role(13)" object might be responsible for the actual hand-shake passing of the work packet.