After dedicating a significant amount of time to researching this topic (for educational purposes), I am prepared to provide a comprehensive explanation of how this code operates.

Let's start by examining the original code along with annotations:

import { pipe, range, timer, zip } from 'rxjs';
import { ajax } from 'rxjs/ajax';
import { retryWhen, map, mergeMap } from 'rxjs/operators';

function backoff(maxTries, ms) {
  return pipe(
   retryWhen(attempts => range(1, maxTries)
     .pipe(
       zip(attempts, (i) => i),
       map(i => i * i),
       mergeMap(i =>  timer(i * ms))
     )
   )
 );
}

ajax('/api/endpoint')
  .pipe(backoff(3, 250))
  .subscribe(data => handleData(data));

function handleData(data) {
  // ...
}

1. Creating a custom operator called backoff using the existing retryWhen operator allows us to apply it within the pipe function later on.
2. The pipe method in this context returns a customized operator.

3. Our customized operator is essentially an altered version of the retryWhen operator. It accepts a function as an argument which will be executed once, specifically when this retryWhen function is first triggered. The retryWhen only comes into play when the source observable encounters an error, halting further error propagation and resubscribing to the source. If the source produces a non-error result, the retryWhen is bypassed.

   With regards to attempts, it is an observable created exclusively for the retryWhen function and is used to react to each failed subscription attempt to the source observable.

   So, here is what we're going to do.

   Initially, we generate range(1, maxTries), an observable that provides an integer for every potential retry. Although range can emit all its numbers immediately, we need to synchronize it with the retries. This is why we...

4. ...zip it with the attempts, pairing each emitted value of attempts with a respective value from range.

   At the moment this function is executed, attempts has fired a single next event — indicating the initial failed subscription. Thus, our zipped observables have produced just one value at this stage.

   Regarding the values in the combined observable, the function determines this: (i) => i. To clarify, it could be written as

   (itemFromRange, itemFromAttempts) => itemFromRange

   . Since the second argument is unused, it is omitted, and the first is renamed as i.

   Essentially, we ignore the actual values emitted by attempts and solely focus on acknowledging their occurrence while progressing through the sequence of range observable...

5. ...and squaring the integers for the exponential increase part of the backoff strategy.

   Subsequently, whenever a (re-)subscription to the source fails, we possess a growing integer sequence at our disposal (1, 4, 9, 16...). How do we convert these integers into time delays until the next re-subscription?

   It is crucial to note that the current function must yield an observable using attempts as input. This resulting observable is constructed only once. retryWhen then subscribes to this output and retries subscribing to the source observable whenever this derived observable emits a next event; terminates or triggers an error on the source observable based on the outcome of the derived observable.

6. In brief, we require the retryWhen to pause momentarily. While the delay operator might suffice, setting up an exponentially growing delay would likely be cumbersome. Consequently, the mergeMap operator emerges as a solution.

   mergeMap effectively merges two operators - map and mergeAll. Firstly, map transforms each ascending integer (1, 4, 9, 16...) into a timer observable that delivers a next signal after a designated number of milliseconds. Subsequently, mergeAll ensures that retryWhen truly subscribes to the timer observables. Without this step, the resultant observable would immediately emit a next event containing the timer instance.

7. At this juncture, we have successfully formulated a custom observable to guide the behavior of retryWhen concerning the timing of subsequent attempts to reconnect to the source observable.

As currently structured, there are two dilemmas associated with this approach:

• Upon the final emission of the last next event by our derived observable (triggering the final reconnection attempt), an immediate complete event is generated. Unless the source observable promptly yields a response (assuming the ultimate retry proves successful), this outcome will be disregarded.

  This stems from the fact that following the receipt of a complete signal from the derived observable, the retryWhen invokes complete on the source observable, potentially while it remains engaged in an AJAX request.

• If all retries prove unsuccessful, the source instead signals complete as opposed to the more logical option of signaling an error.

To address both issues, my proposed remedy incorporates firing an error right at the conclusion of the process, granting the final retry a reasonable window to fulfill its objectives.

Below is the revised implementation including adjustments for the deprecation of the zip operator in the latest version of rxjs v6:

import { delay, dematerialize, map, materialize, retryWhen, switchMap } from "rxjs/operators";
import { concat, pipe, range, throwError, timer, zip } from "rxjs";

function backoffImproved(maxTries, ms) {
    return pipe(
        retryWhen(attempts => {
            const observableForRetries =
                zip(range(1, maxTries), attempts)
                    .pipe(
                        map(([elemFromRange, elemFromAttempts]) => elemFromRange),
                        map(i => i * i),
                        switchMap(i => timer(i * ms))
                    );
            const observableForFailure =
                throwError(new Error('Could not complete AJAX request'))
                    .pipe(
                        materialize(),
                        delay(1000),
                        dematerialize()
                    );
            return concat(observableForRetries, observableForFailure);
        })
    );
}

Following extensive testing, this modification appears to perform reliably under various scenarios. I won't delve into detailed explanations at this moment, assuming most readers may overlook the lengthy discourse above.

Special thanks to @BenjaminGruenbaum and @cartant for guiding me towards the correct path in resolving these complexities.