Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Though the SingleThreadFetcherManager is annotated as Internal, it actually acts as some-degree public API, which is widely used in many connector projects:
flink-cdc-connector, flink-connector-mongodb and soon.

More over, even the constructor of 
SingleThreadMultiplexSourceReaderBase   (which is PublicEvolving) includes the params of SingleThreadFetcherManager   and FutureCompletingBlockingQueue  . That means that the SingleThreadFetcherManager  and 
FutureCompletingBlockingQueue  have already been exposed to users for a long time and are widely used.

public SingleThreadMultiplexSourceReaderBase(
    FutureCompletingBlockingQueue<RecordsWithSplitIds<E>> elementsQueue,
    SingleThreadFetcherManager<E, SplitT> splitFetcherManager,
    RecordEmitter<E, T, SplitStateT> recordEmitter,
    Configuration config,
    SourceReaderContext context)
{ super(elementsQueue, splitFetcherManager, recordEmitter, config, context); }

As shown in FLINK-31324, FLINK-28853 used to change the default constructor of SingleThreadFetcherManager.However, it influenced a lot. Finally, the former constructor was added back and marked asDeprecated。

Therefore, why not make SingleThreadFetcherManager and FutureCompletingBlockingQueue PublicEvolving?

Public Interfaces

Change SingleThreadFetcherManager ,  FutureCompletingBlockingQueue   and parent class SplitFetcherManager  from Internal  to PublicEvolving .

Proposed Changes

nothing else to do.

Compatibility, Deprecation, and Migration Plan

Any change to  SingleThreadFetcherManager , FutureCompletingBlockingQueue   and parent class SplitFetcherManager  later will be careful for compatility.

Test Plan

nothing else to do.