Why not reference DelayedDeliveryTracker at the interface level, which would also apply to BucketDelayedDeliveryTracker?

What you mean is why not to implement DelayedDeliveryTracker directly, but to add a TopicDelayedDeliveryTrackerManager?

Oh I see，you have designed a new data structure for the InMemoryTopicDelayedDeliveryTrackerManager, unable to adapt to other DelayedDeliveryTracker.

Yes.

At the code level, the new TopicDelayedDeliveryTrackerManager already exposes createOrGetTracker(AbstractPersistentDispatcherMultipleConsumers) returning the DelayedDeliveryTracker interface:

public interface TopicDelayedDeliveryTrackerManager extends AutoCloseable {
    DelayedDeliveryTracker createOrGetTracker(AbstractPersistentDispatcherMultipleConsumers dispatcher);
    // ...
}

so the dispatcher only depends on the DelayedDeliveryTracker interface and not on the concrete in-memory implementation. The InMemoryTopicDelayedDeliveryTracker is just one implementation that acts as a proxy to the shared topic-level manager in this PIP.

In the PIP text I focused on the in-memory implementation (e.g. InMemoryTopicDelayedDeliveryTracker*) because this proposal explicitly keeps BucketDelayedDeliveryTracker out of scope (see the “Out of Scope” section). The goal of PIP-448 is to address the memory footprint of the legacy in-memory tracker first, without changing any semantics of the persistent, bucket-based tracker.

Whether it's possible to consider using a special cursor to replay delayed messages to build shared delayed message tracker, instead of relying on the subscription-level DelayedDeliveryTracker to forward messages?

We can check and poll the scheduled message IDs from the shared delayed message tracker to add to the replay queue (MessageRedeliveryController) of all subscriptions.