In bug #53196 comment #1, Werner illustrates a case where it makes sense for hyphenation points that the user defines with .hw to override the global hyphenation value set with .hy.

I believe there are equally valid cases where the opposite should hold.  (See rationale below.)

Thus I am requesting a groff enhancement whereby the user can control whether a document's .hy setting affects hyphenation points defined with .hw.  This could be implemented via a new request, new values for .hy (which so far uses only 6 of its available 32 bits), or some other means.

Or for more flexibility than a new global flag, the .hw request could accept two different hyphenation markers in its words (- and +, say) to differentiate hyphenation points that should be subject to .hy from those that should not.

Rationale:

Typically, one varies the hyphenation freedom (via the .hy request) based on the column width.  In a document that alternates between wide and narrow columns multiple times, one might adjust the value of .hy at each of these alternation points.

As it stands, to get the full benefit of these changes, at each of these points the user must also redefine words defined with .hw.  This becomes cumbersome in documents with many such words.

While the .hw variations can be wrapped in macros, this is still more effort than just having a mechanism to control how .hw words are interpreted by .hy, and also requires that the user maintain (at least) two versions of the .hw list.  Requiring redundancy in source code is how inconsistencies crop up.  This is the sort of task perfectly suited for an algorithm, and should not need manual intervention.