@noisysocks is already including most of these changes in #1804. Excluding filter, because filter was added in a different way than the others (in lib/global-styles.php) instead of lib/compat.php. Should we just update the plugin to add this in lib/compat.php and update Robert PR to contain all kses changes and remove kses from here?

Unfortunately, we need the kses changes in this PR so the code works. Perhaps if this lands quicker than #1804, those changes can be removed from there.

#1804 will land last. If there is overlap then it will come up when I rebase my PR, so no worries 🙂

Changing the method signature could be a breaking change for backwards-compatibility. However, there is a proper value and data type check ===. Should be okay.

Does it make any difference that this class is marked as @private? Hence, it's expected that it's not used by anyone.

No not really. private is just a suggestion in WordPress, the whole code is public.

You do either this

public static function get_merged_data( $deprecated = array(), $origin = 'user' ) {
              if ( ! empty( $deprecated ) ) {
		 _deprecated_argument( __FUNCTION__, '5.9' );
	      }

or

public static function get_merged_data( $origin = 'user' ) {
              if ( is_array( $origin ) ) {
		 doing_it_wrong( 'Do not pass array here', '5.9' );
	      }

Does it make any difference that this class is marked as @Private? Hence, it's expected that it's not used by anyone.

Yes, it should make a difference.

Here's my understanding of @access private:

Marking a global function or class as @access private means: it's only used in and by Core. It's internal functionality. There's no binding contract for or guarantee of backwards-compatibility externally.

From the Core handbook:

@access: Only used for core-only functions or classes implementing “private” core APIs. If the element is private it will be output with a message stating its intention for internal use.

This function should be marked as private prefixed with "_". This is internal only and we should look into renaming these color functions ASAP before any beta version of 5.9 comes out. The functions should be named in what they do and not where the inspiration comes from. Now we don't even use tinycolor on the client, we should not use a port of it on the server. We should look into what color functions we need on the server and name them accordingly.
This is an issue that comes from WP 5.8 so it is not a blocker provided we mark it as private with a to-do comment to remove or rename.

33a0355

Not something related to this PR something we should look into the plugin. We accept many named colors not just transparent, one can select "red", "pink" etc. If we have a case to deal with a named color we should probably deal with the others.