I would like to challenge this decision. You are making the right observations but to be frank I don't understand your conclusion. Let's go through your criteria: virtual type names should be consistent with other names in Magento Makes sense, but which names? Since virtual types are a pure XML configuration thing, why should they be named like PHP classes? The naming could be consistent with other unique things like observer names and indexer ids (module_virtual_type_name) or if that's a M1 relict, ACL resources and templates (Vendor_Module::virtual_type_name) naming should help provide backward compatibility If "we already started doing it it this way and don't want to change it" is a strong argument, this will limit moving forward Magento 2 in many aspects. So let's be open for change if it's an improvement. Backwards compatibility is not even that hard in this case: keep the old virtual types and add the same with the new naming convention next to it (can you mark XML as deprecated?) naming should not expose implementation details (when some object injects a dependency it should not matter whether it is a virtual type or real PHP class) This contradicts the next point... naming should help a developer discover code (where to search for injected dependency: in di.xml or in PHP code?) ... which should be high priority for better developer experience IMHO. You say "If you are using the PhpStorm Magento 2 plugin, it allows developers to navigate to virtual type declarations or to PHP class source code. Nevertheless, Magento does not want to impose any IDE or other tools. Developers should work with an environment that is comfortable for them." For me, PhpStorm and the plugin are a must have, so I'm not even feeling imposed. But if any code requires non-standard tools to even understand and navigate it effectively, this is a very bad sign. In this case it is even without good cause and could easily be avoided. I can only imagine one reason to want virtual types to be transparent (i.e. looking like real types): the ability to exchange them with a real class as needed. But if you want to do this, you will need to change the definition in di.xml anyways, so it's not making anything significantly easier. Please let me know if I'm missing something. avoid conflicts of virtual types and PHP classes Easy: Don't name them like PHP classes ;-) naming should allow introduction of nested scopes This is something I don't really understand. Do you mean namespaces? There are already too many nested namespaces in Magento, but "sub_sub_sub" works just as well as "Sub\Sub\Sub". To be fair, you did not mention this as argument for one or the other solution. In conclusion, I would like to know more about your reasons not to use Vendor_Module::virtualTypeName, which would be a perfect solution IMHO.
... View more