Return to Answer

(Testing done on SQL Server 2022 - 16.0.4055.4 as we don't have access to this sort of thing in Azure!)

DECLARE @T TABLE
(
Id INT IDENTITY PRIMARY KEY  WITH (XML_COMPRESSION = ON),
TestXml XML
)

DECLARE @Xml XML = REPLICATE(N'<a>a</a>',41)
SELECT DATALENGTH(@Xml)

INSERT @T
VALUES (@Xml)

DECLARE @DynSQL NVARCHAR(MAX) = 
(
SELECT  DbccCommand = CONCAT('DBCC TRACEON(3604);DBCC PAGE (', DB_ID() ,', ', file_id ,', ', page_id ,', 3);DBCC TRACEOFF(3604)')
FROM @T
cross apply sys.fn_PhysLocCracker(%%physloc%%)
)

EXEC (@DynSQL);

DECLARE @T TABLE
(
Id INT IDENTITY PRIMARY KEY  WITH (XML_COMPRESSION = ON),
TestXml XML
)

DECLARE @Xml XML = REPLICATE(N'<a>a</a>',41)
SELECT DATALENGTH(@Xml)

INSERT @T
VALUES (@Xml)

DECLARE @DynSQL NVARCHAR(MAX) = 
(
SELECT  DbccCommand = CONCAT('DBCC TRACEON(3604);DBCC PAGE (2, ', file_id ,', ', page_id ,', 3);DBCC TRACEOFF(3604)')
FROM @T
cross apply sys.fn_PhysLocCracker(%%physloc%%)
)

EXEC (@DynSQL);

At the moment this is a partial answer.

It was confirmed on the Azure announcements post that it uses Xpress Compression Algorithm AKA LZXpress.

This has a few variants.

"The first 256 bytes represent the Huffman code lengths" - so that explains the section

I still need to look into various aspects - including how very small XML fragments are treated where this overhead would be too large.

It was confirmed on the Azure announcements post that it uses Xpress Compression Algorithm AKA LZXpress.

The documentation states

This algorithm efficiently compresses data that contain repeated byte sequences. It is not designed to compress image, audio, or video data. Between the trade-offs of compressed size and CPU cost, it heavily emphasizes low CPU cost. Source

and

A protocol that depends on this algorithm would typically need to transfer significant amounts of data that cannot be easily precompressed by another algorithm having a better compression ratio. Source

This has a few variants.

"The first 256 bytes indicate the bit length of each of the 512 Huffman symbols" - so that explains the section

Given the overhead described above even if the XML is highly repetitive it is unlikely that the compression will save any space unless DATALENGTH of the XML is at least 300 bytes.

For values where the "compressed" form would be longer it just stores it uncompressed (as can be seen when changing 41 to 40 below)

DECLARE @T TABLE
(
Id INT IDENTITY PRIMARY KEY  WITH (XML_COMPRESSION = ON),
TestXml XML
)

DECLARE @Xml XML = REPLICATE(N'<a>a</a>',41)
SELECT DATALENGTH(@Xml)

INSERT @T
VALUES (@Xml)

DECLARE @DynSQL NVARCHAR(MAX) = 
(
SELECT  DbccCommand = CONCAT('DBCC TRACEON(3604);DBCC PAGE (', DB_ID() ,', ', file_id ,', ', page_id ,', 3);DBCC TRACEOFF(3604)')
FROM @T
cross apply sys.fn_PhysLocCracker(%%physloc%%)
)

EXEC (@DynSQL);