Quote Block text alignment conflicts with added position alignment support

[grappler]

Description

I have added align support to the quote block. The code that I used can be found below.

This conflicts with the align attribute in the quote block which is used for text alignment with the block.

I would have expected for the attribute to be named textAlign instead of align.

Step-by-step reproduction instructions

1. Add align support to quote block

import { addFilter } from '@wordpress/hooks';
const enableAlignmentOnBlocks = [  'core/quote' ];
// Add alignments to group block.
const addAlignmentToBlocks = ( settings, name ) => {
	if ( ! enableAlignmentOnBlocks.includes( name ) ) {
		return settings;
	}

	return {
		...settings,
		supports: {
			...settings.supports,
			align: [ 'left', 'center', 'right' ],
		},
	};
};
addFilter( 'blocks.registerBlockType', 'mcs-blocks/alignments/group-block', addAlignmentToBlocks );

2. Add the quote pattern
3. Get an error "Block validation: Block validation failed for core/quote" and changing the alignment changes both the position and text alignment

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 5.8/5.7.2

Pre-checks

• I have searched the existing issues.
• I have tested with all plugins deactivated except Gutenberg.

[youknowriad]

Indeed, I'm not sure that the Quote block is the only one in this situation. This is unfortunately "historic". Meaning when these attributes were added, block supports didn't exist yet and they evolved organically after that. We could consider renaming the existing attribute which would require a deprecated version I think. We may have to check what other blocks do the same.

[ellatrix]

Cc @t-hamano

[t-hamano]

The current align attribute, which actually means text alignment, needs to be migrated to the new textAlign block support.

Tracking Issue: #60763

The new textAlign block support should no longer conflict with the align block support, since it's saved as a style instead of an attribute.

But we need to first resolve the style override issue that this PR attempts to address: #62260