What happens... if an event is "equally important" to two aggregates of different types (assuming they are inside the same bounded context) or if even it refers to two instances of the same aggregate type

event-sourcing is a simple (note: not easy) idea. Instead of overwriting previous state when we save an aggregate to our stable storage, we write a new version, linked back to the previous version. Furthermore, instead of writing out an entire copy of the new version, we write out a diff, and the diff is expressed in a domain specific way.

Saving an aggregate to a stream, therefore, is analogous to saving a representation of the aggregate as a document in a key value store, or as rows in a relational database.

When you ask "which stream" does it belong in: it belongs in the stream of the aggregate that changed, just as it would in either of those other storage strategies.

If you aren't sure which aggregate changed, then what you have is a modeling problem, not an event sourcing problem.

Both of your examples describe introducing a relation between two aggregates; it's analogous to having a many to many relationship between two tables in a database. So who owns the M2M table?

Well, if neither aggregate needs that information to ensure its own invariant, then the M2M table might be an aggregate all by itself.

Imagine a representation of a contract between two parties - it might turn out that the two parties are incidental, and "Contract" is the important idea, worthy of being modeled as its own thing.

If the relation is clearly "part of" one aggregate (that aggregate is guarding invariants that depend on the state of the relation), then that aggregate will be responsible for editing the new table, and the other aggregate will ignore it.

If both aggregates care about the relations, then you have one of two problems

1) Your analysis of the domain is wrong - you've drawn your aggregate boundaries in the wrong place. Get thee to a white board and start drawing things out.

2) You have two copies of the relation -- one for each aggregate, but those copies aren't necessarily consistent with each other.

Here's an important heuristic: if you really have two different aggregates, you should be able to store them in two completely different databases. They can't share each other's data, but they can keep their own versioned/timestamped/cached copy of the other guys data.

So left-hand-aggregate makes a change, and the "plumbing" sends a "left-hand-aggregate-changed" message to right-hand-aggregate, then right-hand-aggregate updates his cache.

Note how this would work in the case where we think the contract is a first class concern that manages its own state. The model updates the contract, saving the changes to its state, and then the plumbing comes along and delivers a copy of the changes to each of left-hand-aggregate and right-hand-aggregate.

Simple. Not necessarily easy.

I don't think it has anything to do with event sourcing per se. Perhaps the design can be tinkered with a bit.

I would go with something like this for the locomotive:

public class Locomotive
{
    Guid Id { get; private set; }
    Guid? AttachedWagonId { get; private set; }

    public WagonAttached Attach(Guid wagonId)
    {
        return On(
            new WagonAttached
            {
                Id = wagonId
            });
    }

    private WagonAttached On(WagonAttached wagonAttached)
    {
        AttachedWagonId = wagonAttached.Id;

        return wagonAttached;
    }
}

The event stream for the Locomotive is where the WagonAttached event will reside. In what way the Wagon aggregate is dependent on this event is what is up for debate. I would argue that the wagon probably doesn't care much much in the same way that a Product isn't too concerned with which Order (may in this case) it is related to. The aggregate Order is the side that seems more appropriate for the OrderItem associative entity. I'm guessing that your locomotive-to-wagon relationship would probably follow the same pattern given that a locomotive would have more than one wagon attached. Probably a bit more to the design but I'm going to assume that these are hypothetical examples.

The same goes for the Issue. If one could attach multiple then the Order to Product concept comes into play. Even though two issues are involved there is a direction of sorts given that one issue, as a subordinate, is attached to the primary issue. Perhaps event with a RelationshipType such as Dependency, Impediment, etc. In such as case one would probably go with a value object to represent that:

public class Issue
{
    public class RelatedIssue
    {
        public enum RelationshipType
        {
            Dependency = 0,
            Impediment = 1
        }

        public Guid Id { get; private set; }
        public RelationshipType Type { get; private set; }

        public RelatedIssue(Guid id, RelationshipType type)
        {
            Id = id;
            Type = type;
        }
    }

    private readonly List<RelatedIssue> _relatedIssues = new List<RelatedIssue>();

    public Guid Id { get; private set; }

    public IEnumerable<RelatedIssue> GetRelatedIssues()
    {
        return new ReadOnlyCollection<RelatedIssue>(_relatedIssues);
    }

    public IssueRelated Relate(Guid id, RelationshipType type)
    {
        // probably an invariant to check for existence of related issue

        return On(
            new IssueRelated
            {
                Id = id,
                Type = (int)type
            });
    }

    private IssueRelated On(IssueRelated issueRelated)
    {
        _relatedIssues.Add(
            new RelatedIssue(
                issueRelated.Id, 
                (RelatedIssue.RelationshipType)issueRelated.Type));

        return issueRelated;
    }
}

The point is that the event belongs to a single aggregate but still represents the relationship. You just need to identify the side that makes the most sense.

The events can (or should) also be published using some event-driven architecture method (say a service bus) in order for other interested parties to be notified.