This seems like it would get the wrong result for:

$a;
        <-- Some trailing whitespace here on this line.
  $b;

Specifically, I would expect the str_replace() at the end to start with an input like <space><space>\n<space><space>, then remove the \n and incorrectly return $b as indented 4 spaces.

Am I misreading?

Right, I guess I am not correctly handling the case in which the whitespace contains more than one newline character.

I'm thinking that I should write some unit tests here

OK. This seems to work better now. I tested this using D12296 on the following file:

<?php

function foo() {
  $x = array(
    1,
    2,
    3);
       
  $y = array(
    1,
    2,
    3);
  
  $z = 
      array(
    1,
    2,
    3);
}

The output (after applying autofixes) was as follows:

<?php

function foo() {
  $x = array(
    1,
    2,
    3,
  );

  $y = array(
    1,
    2,
    3,
  );

  $z =
      array(
    1,
    2,
    3,
      );
}

I sort of wonder if this should return something else that makes it easier to patch, but let me look at D12296...

In D12295#122305, @epriestley wrote:

Ah, irrelevant for D12296.

My thinking here is that if we eventually write a lint rule which adjusts indentation, it couldn't original/replacement a single token because this method may split tokens apart. But I'm not really sure what would be better to return without being a total mess, and such a rule might reasonably use a more top-down approach to analyzing the entire file.

I'm not sure that I follow... this method is only dealing with a single token (although it does destroy the original value of the token, is that your concern?).