How about dropping the deprecation here?

Hmm.. I see then it would collide with the the title which is declared as an object.

I think the best way of handing these cases today is to change the title valType to be any and then support both String and Object types so that when title is a string title.text is set to the string.
How about opening a new PR with this approach?

@archmoj That sounds fine but I'm unsure about the attributes syntax for accepting both an object (with specific nested keys) and a string... this is the attribute definition right now for title in colorbar:

    title: {
        text: {
            valType: 'string',
            description: 'Sets the title of the color bar.'
        },
        font: fontAttrs({
            description: 'Sets this color bar\'s title font.'
        }),
        side: {
            valType: 'enumerated',
            values: ['right', 'top', 'bottom'],
            description: [
                'Determines the location of color bar\'s title',
                'with respect to the color bar.',
                'Defaults to *top* when `orientation` if *v* and ',
                'defaults to *right* when `orientation` if *h*.',
            ].join(' ')
        }
    },

My point is that there doesn't seem to be a place to define valType for title if we are also defining nested attributes under title. Do you have a suggestion?

Let's see what @alexcjohnson would suggest here.

How about keeping the valType as Object with and add an extra option for this case?

Or perhaps we should just handle this String option on the plotly.py side?

@archmoj Do you have an example of an extra option being used elsewhere in the codebase?

Something like this: https://github.com/plotly/plotly.js/pull/6990/files#r1591049384
Instead of extra you may add another option to coerce and name it stringOk or something else.

@archmoj These tests should also be included in #7262 , right?