>I am imagining that I am a solution architect Y waiting for requirements gathering to finish.  Say, the plan says that X should send his work to Y. Is there a way for a planner or manager to capture this intent in Jazz?

there is no way to capture this intent in the out of the box system.
and he should never be 'waiting'. there was A requirement completed. It shows in the list of new workitems for architects and he take he next one to work on.

the part of 'it shows in the list of new workitems' can be automated (scripting, coding, out of line workflow tools), but is not automated out of the box.

each user has a dashboard of work assigned to them, each workitem has a priority, so the user could sort the dashboard (aka inbox) in priority order.

so it is really like 4.

4. X completes his work and informs the planner or manager M.  M does either option 2 or option 3.

I'll call it 5. X completes his work. The planner or manager M (can be), informed of completed work does either option 2 or option 3.
the default mechanism is the use of a query on the planner/manager M dashboard that shows completed work of type X. and their process step is to assign next steps to an actor.
or you could have 6.
X completes his work. Actors q, t, y and r see the list of current and incoming work, and decide among themselves who will take what part of that. (assign it to themselves)

the Kanban view is to show where the work it at a higher level..
a) sitting in the incoming queue
b) being worked on
c) completed.
a & b can be analyzed  ad infinitum as to the causes for delay or expediency.

all of this presupposes a creation of discrete units of work of the appropriate types in advance.
this is the work decomposition phase, which is required of any project.
RTC's workitems (out of the box), encapsulated in each project area are really the lowest level elements.

I am not a formal process engineer. 
IBM has tooling to help in this space: Rational Method Composer
and there is a connection with RTC (ie use MC (aka RUP) to create the model,
then create a matching project area process description.

here is a workshop I found (google) to assist in the use of MC and RTC to create that higher level process model.
Process Composer workshop

but you must do the process creation. (there may be models available already)

RTC of itself does not implement nor enforce any particular high level requirements to delivery model.

You can use many of the parts to implement a complete auditable process, but it is on you to do so.

Requirements gathering and elucidation is the purpose of Requirements Manager
Quality definition and verification is the purpose of Quality Manager.

If you need higher level requirements portfolio mgmt, then you need to add FocalPoint to the mix.
If you need Architecture and design storage and facilitation, then you would add System and/or Software Architect.

RTC's job in the middle is to  allow the development team to take validated requirements (see Focal Point and RM), with whatever certification you choose,  and organize the work into waterfall (one big iteration) or agile (many small iterations) or kanban (like waterfall, but with a developer driven on demand processing model).

RTC provides raw artifacts to help document and organize the work,  Epic, Story, Task, Defect, Impediment, Adoption Item and Retrospective. You can add more as suits your needs.

Inside each artifact is a processing model which is very neutral out of the box, but can be customized however you desire. but it is INSIDE the artifacts.
there is no mechanism to implement nor enforce a higher level workflow or business process like u describe.

Some consider Kanban to support a high level business process (deliver working function x to customer y),
and the work (collection of epics, storys, tasks), flow thru the high level steps (requirements elucidation, planning,
development, test, delivery), and the task board shows where in the high level workflow the collection is.
RTC does not provide that high level flow model.

How does this work with a "real projects with tens/hundreds of participants? ", the high level process is managed somewhere else..
but if u step back they are all the same.

requirements in, process in the middle, content out.
the artifacts used for each stage are fairly similar, almost identical in each processing model. discrete units of work with predictable ins and outs (if the actors do their tasks properly and to completion).

" Also, I am told that there is no natural way to make a person aware of when it is their turn to act once their predecessors have completed their activities. ".

correct,. that is because the model here is COLLABORATIVE Lifecycle Mgmt. all the actors are assumed to be actively engaged all the time, regardless of the central development process,

and thus they participate in the work constantly.. there is no 'when it is their turn'. it is ALWAYS their turn.

the engine here constantly takes inputs and delivers outputs. requirements mgmt delivers new work, development takes it as fast as possible, and delivers to the verification and delivery stages as fast as they can, verification and delivery are always working on the stuff coming down the conveyor belt to them. this is an assembly line.
no 'beginning, middle or end', just a constant flow.  (many iterations). the entire team meets constantly (daily standups) to articulate how the gears of the process are engaging (or not).

you can decide to do this whole thing once (waterfall) or not (agile).

Jazz provides the framework such that all the components of a complete lifecycle can communicate and participate in the large process (regardless of the specific model being executed) thur standard (OSLC) interfaces in the hope that this will reduce the integration workload to the business process and not the glue layer (point to point integrations) between them.

"Now, lets say that the project moves from "planning" phase (say, for Release 1) to the "doing" phase for that release." there is no delineation here. the actors with planning responsibility are always planning and the executors are always executing.
you 'could' implement a formal delineation, by using new artifact. and using workitem approvals to document the facts.  but RTC does not provide this out of the box.