This should probably start with something like

A delegate that manages ...

why would this become public? I think the synthesize selection events logic is implementation details.

ah this is for subclass to implement their selection logic. It would be good if we can provide some sort of low level selection API, for example

void updateInternalStateBeforeAndAfterSelection(child, callback) {
  ensureChildUpdated(child);
  callback();
   _hasReceivedStartEvent.add(child);
   _hasReceivedEndEvent.add(child);
}

and then subclass can do

SelectionResult handleSelectParagraph(event) {
 for(..) {
    updateInternalStateBeforeAndAfterSelection(selectable,() {_handleSelectParagraph} )
 }
}

If we can't completely hide these internal state, at least make them readonly, so that only one class is updating the state.

I think i missed this, why do we need to duplicate these two method in this class?

I did this to handle the behavior where to keep the origin boundary within the selection we swap the selection edges when they invert. We didn't need this for word boundary because a word boundary is guaranteed to be within one _SelectableFragment, but with paragraphs the origin boundary may span multiple _SelectableFragments so I needed to account for these swaps at the container level so it has an accurate currentSelectionStartIndex and currentSelectionEndIndex.

Nit: Maybe point people towards MultiSelectableSelectionContainerDelegate for cases that DO move around? If that's not already obvious.

Looking at this nowadays, not sure if I understood correctly but there is a reference to MultiSelectableSelectionContainerDelegate in the "See also" so seems good now.

Nit: "event" => "events"? Or "the most up to date selection event"?

Oh was this PR prompted by the issue about putting a newline between copied widgets?

Yes, and anyone trying to use SelectionContainer has to re-implement or copy and paste a lot of this logic since it requires a SelectionContainerDelegate.

Could this be done near the top of the widget tree for a big app with a single SelectionContainer, so that nearly everything has this newline behavior? Or would you need to do a bunch of SelectionContainers?

It would still need multiple SelectionContainers because getSelectedContent does not propagate down the tree.

before a [SelectionEvent] is dispatched to a [Selectable]

The naming for these method should be describing what condition will trigger this method instead of describing what the internal logic does. Something like
didReceiveSelectionEdgeEventFor();.

The current name may not make sense after several level of subclassing

Or maybe handleSelectionEdgeEventFor? I always look at this in the style guide but not sure if it applies here: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md#naming-rules-for-typedefs-and-function-variables

I think handle* may be confusing since we already have methods like handleSelectWord, and handleSelectionEdgeUpdate. didReceive makes a good distinction since these methods are only tracking the events and not actually doing any of the logic that moves a selection edge.

Can you also mention in what condition subclass may want to override/calling this method?

same, this should probably named didReceiveSelectionBoundaryEvents

same for other methods

is there any subclass that uses this method?

Not at the moment, but it is used by public methods like remove and dispatchSelectionEventToChild, so I think if someone extends this delegate they may want access to this method.

Just wanted to check if this name would be any better if it was shorter. Maybe MultiStaticSelectableDelegate or StaticSelectablesSelectionContainerDelegate?

Updated to StaticSelectionContainerDelegate, open to other suggestions. We have a private _ScrollableSelectionContainerDelegate, so I think this name makes sense given that convention.

Looking at this nowadays, not sure if I understood correctly but there is a reference to MultiSelectableSelectionContainerDelegate in the "See also" so seems good now.

Or maybe handleSelectionEdgeEventFor? I always look at this in the style guide but not sure if it applies here: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md#naming-rules-for-typedefs-and-function-variables

Super nit: I wonder if it's better to put the SelectionContainer above the Center? I'm guessing most people will use this to cover everything under as single SelectableRegion. Or is there any benefit to keeping this as-is?

That makes sense to me, updated.

Nit: Maybe a switch on forEnd?

If we expose clearInternalSelectionStateForSelectable, this should be a for loop to call clearInternalSelectionStateForSelectable

the doc should mention sub class should clean up state they added in didReceive- method

same for the didReceive method that state should be clean up in this method