The problem is not alone with pagesincategory, all other parser functions which takes a title have this problem, see also bug 16474.

There's a workaround which is to redecode the parameter of PAGESINCATEGORY with #titleparts.

But I'm still convinced that we should not have to use this trick in wikicode, given that there should not exist any valid category name containing verbatic character entities (it is still possible that they exist, because we have allowed litteral ampersands in pagenames without requring them to be HTML-encoded with named entities, so this causees an ambiguity (but I'm not convinced that we have any valid page name containing verbatim named entities; and not that it's impossible to include verbatic sharp signs "#" so you cannot include verbatim numeric entities).

So what we could do is to HTML-encode quotes, ampersands, and lower-than/greater-than signs, by using numeric entities, instead of named entities (" ' < >), so that they can safely be URL-decoded by PAGESINCATEGORIES (which would continue to treat named entities as verbatim without decoding them automatically like numeric entities.)

Change 145724 had a related patch set uploaded by Brian Wolff:
Have Title::makeTitleSafe decode html entities.

https://gerrit.wikimedia.org/r/145724

It's not just ', " too.

As a workaround, you can use a Lua module to decode the HTML.
https://en.wikipedia.org/wiki/Module:HTMLDecode

And then use {{PAGESINCATEGORY:{{#invoke:HTMLDecode | HTMLDecode | text={{PAGENAME}} }}}}

Using a wiki-dependant Lua module is not a good workaround (also Lua modules are not deployed in all wikis) and slower and more costly than using the builtin parser function {{#titlepart:}} to decode these named or numbered character entities (&, <, >, ",  ,  ,  , and so on) when they are valid (so a & alone or without the correct syntax and the required trailing semicolon must remain intact).

For a character entity to be valid and replaceable during the decoding of the input, there should be nothing else between & and ; than ASCII letters, hyphens, digits for named character entities, or a leading # followed by ASCII decimal digits or a leading # followed by an x and hexadecimal digits for numbered character entities. The named character entities *must* belong to a restricted set as mandated by the HTML5 standard (not every name defined in various non-standard HTML or SGML dialects), and at least the entities generated on ouput of {{PAGENAME}}, plus any valid numeric character entity (for every character which is valid in HTML5, excluding most C0 and C1 controls).

And after this replacement of valid character entities, the standard HTML5 compression and stripping of whitespaces may be applied (as defined in CSS and used by default for rendering of most HTML5 elements, unless these elements are styled explicitly); but note that such compression and stripping is not part of the HTML5 parsing, but only a question of style in the renderer: these whitespaces are actually not compressed/stripped in the HTML5 DOM created by the HTML5 parser, they are left intact in every text element and every attribute value (whitespaces and HTML comments between <and > and surrounding the element names or attributes names or the = sign between an attribute name and attribute value are discarded from the HTML5 DOM, so stripping/compression is not relevant for them, they are only visible in some non-HTML parsers, like XML and SGML parsers used by some debugging tools or editors or data processors, working in advanced mode, which can detect them as unfiltered lexical items to be treated specially in an early parsing step, like also the document declaration and embedded DTD; such special parsing exists in HTML5 but it is an internal step of preparation/adaptation which occurs just after decoding of some transport syntax like Base64/Quoted Pintable encapsulation or MIME and HTTP's multipart attachments, and after decoding the binary character encodings which may be sniffed from the first bytes if it's not provided by some meta information given by the transport layer or when instanciating the parser itself).

So the best workaround is still:

{{PAGESINCATEGORY:{{#titlepart: {{PAGENAME<!--: Optional page name here from some parameter or template-generated-->}} }}}}

because {{#titlepart: ...}} already parses and decode the character entities in its own input parameter (it also strips the leading extra colons and whitespaces before a full pagename, which can also break PAGESINCATEGORY, by normalizing its own parameter to a canonical full page name, it also normalizes the whitespaces/underscores in pagenames, including category page names). The Lua module you suggest still does not perform that.

Ideally, {{PAGESINCATEGORY: ...}} should really parse and normalize its parameter just like what {{#titlepart: ...}} or {{#ifexist: ...}} does, before using it. If this is done, there's no longer need of any workarounds above, and there's no need to change the behavior of {{...PAGENAME[:...]}} functions which can keep the HTML-encoding of their output.

It could also potentially accept a parameter containing the full page name of the category, including one of its known namespace prefixes, to check if the namespace is a category and then drop it along with its next whitespaces, but otherwise it should preserve that namespace, for example when we want to check the number of pages in "Category: User: Someone" ; however, this assumes that there should not exist any category like Category: Category: Some name.

This preparation of the input parameter (parsing and normalization) is also done by {{PAGENAME: <!--Some value here...-->}} and related parser functions {{BASEPAGENAME: ...}} or {{FULLPAGENAME: ...}}, except that these {{...PAGENAME: ...}} functions are unexpectedly reencoding their return value using HTML entities (and this is the origin of this bug), while {{#titlepart: ...}} correctly keeps the return value unencoded.

Only the {{PAGESINCATEGORY: ...}} function unexpectedly doesn't prepare correctly its input parameter (and this is the subject of this bug) before using it.