This is a long-overdue IR. I strongly support the proposed resolution.

However, there are a couple of issues. 

First, the proposal is not, strictly speaking, upward compatible.

suppose you have two functions:

    FUNCTION convert_int(x: integer) RETURN std_logic_vector;

and

    FUNCTION convert_int(x: integer) RETURN bit_vector;


Under existing LRM rules the expression

    IF(convert_int(5) = B"101")...

is unambiguous. Under the new proposal it would be ambiguous.
My feeling is that this is not sufficient reason to reject the
proposal.

Second, the proposal does not address an important related problem.
Under the current language rules, if you use a base
specifier of O then the length of the string produced will always be
a multiple of three. If you use a base specifier of
X then the length of the string produced will always be a
multiple of four. This is a great inconvenience for designers, who
frequently need to specify bit strings which are not multiples of
three or four, or who wish to use X notation (for readability) for strings
of lengths which are not a multiple of four.

One upward-compatible solution to this second problem is to allow
an optional integer between the base_specifier and the bit_value
string. This integer specifies the number of bits in the string.
The details of just how to use this count remain to be worked out,
but the idea is that if the string doesn't contain enough bits, then
a '0' fill (on the left) will be done. If the string contains too many
bits then left bits will be truncated, with an error if any of the
truncated bits are '1'.


E.G.

    X7"7F" -- 7 bits of '1'


What do you think?