Multiple "format" has been broken for us in new v4 version

[extempl]

Use-case we have is more smart formatting with autocomplete, like if you enter 06 - it will assume that it is the 6th of current month of current year. But, and it is important, it were not trigger onChange (or, I assume it were, but didn't autocomplete the input until user explicitly trigger onChange by moving to other field, for example), so user could still add more to that, like 06.05, which would assume it is 5th month of current year.
To make it work we used format list like so

'DD.MM.YYYY', 'DD.M.YYYY', 'D.MM.YYYY', 'D.M.YYYY', 'DD.MM.YY', 'DD.M.YY', 'D.M.YY',
    'DD.MM', 'DD.M', 'D.M', 'DDMMYYYY', 'DDMMYY', 'DDMM', 'DD', 'D'

In the 3.4.7 -> v4 (like antd 5.13.3 -> 5.14.0) refactoring this approach does not work anymore, now it triggers onChange on any format match, like you enter 06 - it completes input with 06/02/2025, and user can't adjust it anymore.

As an additional feature request, I'd probably appreciate formatter/parser functionality with methods, like it is on InputNumber component to make it more stable.

[TokiyaHorikawa]

I'm also experiencing the same issue and struggling with it.
I believe it's due to the user input needing to match the display format. (Though I haven't looked into it in detail.)

[okayumoka]

I'm also experiencing a similar issue since v4.6.8.
Before v4.6.7, '2025/01/02' was accepted in the yyyy/M/D format.
However, since v4.6.8, this format reject '2025/01/02' string.

The cause is the following process in isStrictValidDate, which marks it as invalid if the input text and the formatted text do not equal.

picker/src/generate/dateFns.ts

Lines 67 to 68 in 8a420c4

	const formattedDate = formatDate(date, format, { locale: getLocale(locale) });
	return text === formattedDate;

What is the purpose of this change? Please either revert to the previous behavior or provide a way to allow input like '2025/01/02' as before.