Детали реализации разделителя потоков

Изучая исходный код WrappingSpliterator::trySplit, я был очень введен в заблуждение его реализацией:

    @Override
    public Spliterator<P_OUT> trySplit() {
        if (isParallel && buffer == null && !finished) {
            init();

            Spliterator<P_IN> split = spliterator.trySplit();
            return (split == null) ? null : wrap(split);
        }
        else
            return null;
    }

И если вам интересно, почему это важно, то, например, это:

Arrays.asList(1,2,3,4,5)
      .stream()
      .filter(x -> x != 1)
      .spliterator();

использует его. Насколько я понимаю, добавление любой промежуточной операции к потоку вызовет запуск этого кода.

В основном этот метод говорит о том, что если поток не является параллельным, рассматривайте этот Spliterator как тот, который вообще не может быть разделен. И это важно для меня. В одном из моих методов (вот как я добрался до этого кода) я получаю Stream в качестве входных данных и «анализирую» его на более мелкие части вручную с помощью trySplit. Например, вы можете подумать, что я пытаюсь сделать findLast из Stream.

И здесь мое желание разбиться на более мелкие куски обрывается, потому что как только я это делаю:

Spliterator<T> sp = stream.spliterator();
Spliterator<T> prefixSplit = sp.trySplit();

Я узнаю, что prefixSplit — это null, а это означает, что я в принципе не могу ничего сделать, кроме как потреблять все sp вместе с forEachRemaning.

И это немного странно, может быть имеет смысл, когда присутствует filter; потому что в этом случае единственный способ (в моем понимании) вернуть Spliterator — это использовать какой-то buffer, может быть, даже с предопределенным размером (очень похоже на Files::lines). Но почему это:

Arrays.asList(1,2,3,4)
      .stream()
      .sorted()
      .spliterator()
      .trySplit();

возвращает null — это то, чего я не понимаю. sorted — это операция с отслеживанием состояния, которая в любом случае буферизует элементы, фактически не уменьшая и не увеличивая их начальное количество, поэтому, по крайней мере, теоретически это может вернуть что-то отличное от null...