Also tried applying rule using this format:

{"kind":"local","namePattern":"Adult Color Printer"}

I don't think this is a bug. Quoting the policy description:

> This policy determines the rules for selecting the default printer in
> Chromium which happens the first time the print function is used with a profile.
https://www.chromium.org/administrators/policy-list-3#DefaultPrinterSelection

If I'm reading the description correctly, then the policy is not expected to take precedence over the user selections on each browser start. It's used only as a default selection when there's no one made yet.

If the policy isn't applied each time the browser starts, it's pretty much useless from an Enterprise perspective. What value is it for me to have a setting to control the default printer in the browser if any user can change it to something else and have that change stick on subsequent browser sessions?

Aleksey/Vitaly, do you still remember the details of this feature (see  issue 468447 )? Seems that you both don't work on Chrome anymore, but maybe you still have some context on this.

The policy does what it was designed to do, it controls the _default_ printer selection. It is not an adequate tool to solve the problem stated in #1 and it was not intended to address this use case.

Again, from an Enterprise perspective, what's the point of this setting, especially in the context of Group Policies? In what Enterprise is there a need to set the default printer once and then never again for a user? I'm sure there must be some use case where that makes sense but for the vast majority of Enterprise administrators, having a setting that can only be set once and then never controlled again is pointless and in some ways, counterproductive when you discover that the Group Policy settings don't really give you control over the browser in the way that is needed in an Enterprise environment. 

All this might well be a valid feature request, I am not arguing with that.

What I'm saying is that "Default Printer Selection Rules" policy was designed to address a specific use case, it does work as intended, there is no bug to fix. Any new functionality or changes in the existing components should be handled appropriately, as feature requests, not as bugs.

So this issue is not actually a bug, but a feature request. For example, this may be implemented by adding a new separate policy that would work like a forced value without user's ability to override that.

Assigning to David for prioritization.

Seems like a browser issue. Assigning to Philippe for handling.