> I may be in minority, but I find it convenient to use int(), float()
> etc. for data validation.
A number of libraries agree: argparse, HTML form handling libs, etc.

> I may be too strict, but I don't think anyone would want to see
> columns with a mix of Bengali and Devanagari numerals. [...]
> On the other hand there is certain convenience in promiscuous
> parsers, but this is not an expectation that I have from int() and
> friends. [...] There are pros and cons in any approach.
Indeed, tough question.  On one hand, I tend to agree that mixing Hindi/Arab numerals with Bengali does not make sense; on the other hand, rejecting it means that the int code does know about Unicode, which you argued against.

>[MAL]
>> The codecs, Unicode methods and other Unicode support features
>> happily work with all kinds of languages, mixed or not, without any
>> such specification.
> In my view int() and friends are only marginally related to Unicode
> and Unicode methods design is not directly relevant to their behavior.
I think I agree.  It’s perfectly fine that Unicode support features don’t care about the type of the characters but just encode and decode; however, int has a validation step.  It rejects numerals that don’t make sense with the given base for example, so rejecting nonsensical sequences of Unicode numerals makes sense IMO.

What do the other languages that are able to convert from Unicode numerals to integer objects?