How and when should I use Microsoft.Diagnostics.EventSource.WriteEventWithRelatedActivityId(...) method

It seems to me I don't completely understand the mean of this method and the "relatedActivityId" parameter. Correct me please if I'm wrong.

Assume I have two components - A and B. Component A is an infrastructure component and has some entry point (receives messages from some transport and dispatches them to component B. Because it's real entry point of a whole application component A assigns ActivityIDs at the begining of its message processing pipeline. Assume component B wants for some reasons to have its own ActivityIDs for its tasks.

Assume that component B works in the same thread with component A. 

1. It should get and store component A's ActivityId, set new ActivityId to the thread and write some transfer event:

Guid relatedActivityId;
ComponentBEventSource.SetCurrentThreadActivityId(Guid.NewGuid(), out relatedActivityId);
Log.WriteEventWithRelatedActivityId(eventId, relatedActivityId, ...)

2. When component B's part of work is completed it should simply restore component A's ActivityID:

ComponentBEventSource.SetCurrentThreadActivityId(relatedActivityId)

Is it correct usage?

In the case when components A and B work in different threads or even in different processes on different computers I should simply send original ActivityId (may be "over the wire") to the component B and write transfer event on the conponent B's side in order to provide end-to-end tracing. Of course step 2 is not required in this case.

Is it correct?

So I initially consider "relatedActivityId" as activityId of the "parent" or previous component's activity. But when I was looking for examples in .NET BCL I found TPL is instrumented with EventSource. And I see you use "relatedActivityId" as activityId of the child activities. So the parent component writes transfer events. In TPL it's possible thanks to the fact that parent component knows child activityId (it's explicitly constructed from TaskId). Child component still have to replace current thread's activityId and then restore it.

And so I came to the conclusion that both possible. And usage style depends on the specific solution context. From the events consumer's point of view it will be not too complex to recognize what pattern was used by component's developers and to perform end-to-end trace analysis.

Is it correct from Microsoft point of view? Are there any other considerations?