It is certainly possible, the code that does this is fairly simple and I was just mucking with it a few hours ago. However, it is perhaps a bit bigger change than just special-casing packaging; it would be pretty hacky that way, not fit the existing layout and beg the question as to why not for Typing or other things too. There is no unambitious indicator of what counts as a packaging PEP; we’d have to add a new Category field to the PEP header for this unless we hardcode a list somewhere, and they don’t really intersect well with the current way sections are structured, i.e. by PEP status.
I think having a Category header field with a few basic categories like Core, Typing, Stdlib, Packaging, Release, etc. would be very helpful and allow users to find PEPs they are interested in much more easily. To display them, we could make the index page even longer with tables of PEPs by category, such that it would have to be a separate set of sections (which have been rejected in the past for other things).
However, a much better approach would be having the main table of PEPs sortable by each of the headers (number, date, category, status, type, etc). This would add requested and useful functionality without making the page longer (theoretically, we could even omit the currently duplicative tables and just rely on that).
Of course, as to that aspect I believe @AA-Turner would be the best judge. But this all isn’t really a packaging discussion, and might be a better fit for, e.g., the PEPs repo.
Could you point us to the specific comment there where this was discussed? At least skimming through, I couldn’t find it.