I think that you're still not answering the question ;-)
It's not only a matter of VHDL coding style. If most of the vendors supports
the same IEEE packages (numeric_std and numeric_bit) as defined in 1076.6,
some of them still ignore the standardized syntax for the comments intended
to enable/disable the synthesis process. In 1076.6, they are defined as --
RTL_SYNTHESIS ON and -- RTL_SYNTHESIS OFF but some vendors do not support
them (Synplify Pro from Synplicity for instance (please correct me if I make
a mistake)) and most of the vendors support the "de-facto" Synopsys
comments -- SYNTHESIS TRANSLATE_ON and TRANSLATE_OFF.
As a general comment, I would say that 1076.6 defines a synthesis subset w/o
being 100% clear on corner cases. For instance, you might find some VHDL
parsing problems (my favorites are the support for the correct use of the
VHDL namespaces (thanks to Synplify Pro from Synplicity (note that they are
correcting it)), or the correct support for separate VHDL files (thanks to
XST from Xilinx (no idea whether they have corrected it in the last
version)) which are part of the 1076.1 standard but not mentionned in the
1076.6. Support for 1076.6 would not ensure that you're portable between
synthesizers.
As far as I remember, I never encountered 1076.6 compliancy or VHDL parsing
issues w/ Synopsys/DC-Compiler. But when you consider VHDL synthesis, the
quality of VHDL synthesis results is much more important than portability.
Synopsys and Synplicity are top-level products (if you don't care about
unfortunate bugs that any tool might have). XST is also improving quite
fast.
Eric