What if one of my models has two collections of another model?

An event has exactly 1 owner and 0..N hosts. Both owner and host are an AppUser. And a user can own many events and host many events. So we have:

public class AppUser
{
    public int Id { get; private set; }
    public ICollection<Event>? EventsOwned { get; set; }
    public ICollection<Event>? EventsHosting { get; set; }
}

public class Event
{
	public int Id { get; private set; }
	public AppUser Owner { get; set; }
    public ICollection<AppUser >? Hosts { get; set; }

}

So... how do I tie AppUser.EventsOwned to Event.Owner and AppUser.EventsHosting to Event.Hosts? Is there some fluent command that sets the explicit relationship?

And when it comes to deleting, how do I set it that:

1. If an Event is deleted, while it removes that event from the EventsOwned and EventsHosting collections, it does not delete the AppUser.
2. If an AppUser is deleted, for any event in EventsHosting, while it removes that user from Hosts, this deletion does not delete the associated Event.
3. If an AppUser is deleted, it should cascade delete the events in EventsOwned.

Anything I need to set up for these three criteria?

You will need to be explicit with your relationships. For instance the ownership looks like a many-to-one between event and owner, while the hosting looks like a many-to-many.

The first thing will be the Owner-EventsOwned relationship and how the FK will need to be explicitly declared as EF's conventions would be looking for an AppUserId rather than something like an OwnerId since convention follows the Type name, not the property name. This can be done with the FK attribute or via configuration, but given the bi-directional refence on User you may want to configure this explicitly:

modelBuilder.Entity<Event>()
    .HasOne(x => x.Owner)
    .WithMany(x => x.EventsOwned)
    .HasForeignKey("OwnerId");

For the association between Event.Hosts -> User.EventsHosted, this will also need configuration:

modelBuilder.Entity<Event>()
    .HasMany(x => x.Hosts)
    .WithMany(x => x.EventsHosted);

You may want to also configure the joining table for the relationship here.

When it comes to navigation properties my advice is to only introduce bi-directional references where it really makes sense to reference items from one side or the other equally. Normally for something like this with references to users I wouldn't bother with navigation properties on the User side of things unless I'm going to want to do something like project users with a count of events owned and/or hosted. If I want events hosted or owned by I user I can always write queries like:

var userEvents = await context.Events
    .Where(x => x.OwnerId == userId 
        || x.Hosts.Any(h => h.Id == userId)
    .ToListAsync();

... which is often more flexible than getting events via the User:

var user = await context.Users
    .Include(x => x.OwnedEvents)
    .Include(x => x.HostedEvents)
    .SingleAsync(x => x.Id == userId);
var events = user.OwnedEvents.Union(user.HostedEvents).ToList();

Edit: To see what the configuration looks like without bi-directional references we would remove the EventsOwned and EventsHosted from the User table, then when configuring the relationships for the Owner and Hosts, these change to:

modelBuilder.Entity<Event>()
    .HasOne(x => x.Owner)
    .WithMany()
    .HasForeignKey("OwnerId");

modelBuilder.Entity<Event>()
    .HasMany(x => x.Hosts)
    .WithMany();

In the case of Event.Hosts being a many-to-many, EF will expect/create a joining table behind the scenes likely named EventHosts containing the EventId and HostId. If you want to explicitly map this relationship table, then

modelBuilder.Entity<Event>()
    .HasMany(x => x.Hosts)
    .WithMany();
    .UsingEntity("EventHost",
        l => l.HasOne(typeof(Event))
           .WithMany()
           .HasForeignKey("EventId")
           .HasPrincipalKey(nameof(Event.EventId)),
        r => r.HasOne(typeof(User))
            .WithMany()
            .HasForeignKey("HostId")
            .HasPrincipalKey(nameof(User.UserId)),
        j => j.HasKey("EventId", "HostId"));

Details about configuring options for many-to-many relationships are outlined here: https://learn.microsoft.com/en-us/ef/core/modeling/relationships/many-to-many

A common example where you almost certainly want to avoid bi-directional references would be something like tracking a CreatedBy user reference where every entity tracks a CreatedBy and LastModifiedBy reference to a user. You might have 100 entities associated to various users, but mapping those as bi-directional references would have a user table with 200 collections for OrdersICreated, OrdersIModifiedLast, ProductsICreated, ... etc.

As mentioned, a bidirectional reference is useful when both entities might equally share serving as an aggregate root and contain query conditions involving the other. Things are typically kept a lot simpler when defaulting to unidirectional references and adding bi-direction only where it adds practical value.