Why does a setter not work with a specific selection?

Sorry for the poorly worded title but I couldn't figure out how to properly summarize the problem.

I created a chess game where the location is kept by the Board. The pieces do not know their location, with the exception of the King. Any time the King moves, its location is updated with a simple setter-

Gameflow.java

    public static void movePiece(Player player, int pieceSelection, int action) {
        int x = pieceSelection / 10;
        int y = pieceSelection % 10;
        Board board = Board.boardConstructor(); //board is a Singleton
        Piece piece = Board.squares[x][y].getPiece();   
        ...
           if (piece.getType().equals(Type.KING)) {              
                King king = (King) piece;
                king.setXY(endX, endY);
                System.out.println("King moved to " + king.getX() + king.getY()); //prints old location
            }

King.java

public class King extends Piece {
    ...
    public void setXY(int x, int y) {        
        this.x = x;
        this.y = y;
        System.out.println("The King's location is now " + this.x + this.y); //prints new location
    }

The println inside the setter in King.java outputted as expected but the King's location was not being updated elsewhere

I was bamboozled as to why the updated location was not being saved but I nevertheless was able to fix the problem by changing one line-

Gameflow.java

    public static void movePiece(Player player, int pieceSelection, int action) {
            if (piece.getType().equals(Type.KING)) {                
                King king = player.getKing(); // <-- changed how I select the King
                king.setXY(endX, endY);
                System.out.println("King moved to " + king.getX() + king.getY()); //prints correctly
            }

Here is my code that copies the pieces and grabs the king via the player

Player.java

   private Player(String name, boolean isWhite) {
        this.name = name;
        this.isWhite = isWhite;
        if (isWhite) {
            team = createPieces(6);
        } else {
            team = createPieces(0);
        }
    }

    public static Piece[] createPieces(int start) {
        Piece[] team = new Piece[16];       
        int count = 0;
        int end = start + 2;
        for (int i = start; i < end; i++) {
            for (int j = 0; j < 8; j++) {
                team[count] = Board.squares[i][j].getPiece();
                count++;
            }
        }
        return team;
    }

    public King getKing() {
        Piece theKing = Arrays.stream(team).filter(x -> x.getType() == Type.KING).findFirst()
                .orElse(null);
        return (King) theKing;
    }

My problem is fixed but I am none the wiser. Why did that fix my code? Why was it not working earlier?

Piece is an abstract class, team is an array of the player's pieces.

It's hard to say without looking at Board, but I see a number of warning signs: The call to Board.boardConstructor() sounds like it's getting a new board, rather than the existing board. You're almost certainly working with a different instance of a piece in the code. Try replacing your code to get the king with the following:

King king = player.getKing(); // <-- changed how I select the King
System.out.println(Integer.toHexString(System.identityHashCode(piece) + "\t" 
    + Integer.toHexString(System.identityHashCode(king)));

if the two hash codes printed differ, that indicates that they're different instances of the piece and the logic elsewhere is to blame.

Don Hosek pointed out where my problem was coming from but I still needed to investigate further to determine the why so I plugged his code into both my Board and each Team. I expected to find one set of 32 hash codes being printed twice, but instead the result was 64 distinct hash codes, aka 2 sets of unique values.

After further use of the hash codes, I found that it was the Pieces on the Board that were mutating. They changed only once, before the first move, which gave me a strong clue as to the problem.

As is often the case with the most confusing errors, the answer was exceedingly simple. Originally this was a Java terminal game that I moved to Spring/React and while doing so, I transposed two lines of code involved in the creation of a new Game (initialization of the Board and of the Players). The solution was merely swapping them back.

I don't know how I didn't get a more critical error by creating Players before the Board when all the Pieces are instantiated by the Board, and I'm very, very surprised that this small issue was the only noticeable effect from such a serious bug.