This link describes some details why AES192/256 has some complexity and what is history for this challenge.
https://web.archive.org/web/20190708220933/http://www.snmp.com/snmpv3/snmpv3_aes256.shtml

This page says that it's really possible starting from version 5.8:
http://www.net-snmp.org/wiki/index.php/Strong_Authentication_or_Encryption

In short: there was an attempt to add AES192/256 support to RFCs, but it never happened officially.
Cisco company did not wait for that and started to use it, with own technical workaround. Later it became "de-facto" standard and now net-snmp added support of these modes to version 5.8

Currently many Cisco devices support AES192/256 and some NMS (as a manager) too.
Would be great to add such support in Zabbix too, to be competitive.

Unfortunately any example in the Internet or in man pages for any net-snmp package does not mention specificity for new AES modes and how to use them.

Some details can be found only in source code.
Options available for command line are defined in net-snmp-5.8/snmplib/snmpusm.c:

#ifdef NETSNMP_DRAFT_BLUMENTHAL_AES_04
    { "AES-192", USM_CREATE_USER_PRIV_AES192 },
    { "AES192", USM_CREATE_USER_PRIV_AES192 },
    { "AES-256", USM_CREATE_USER_PRIV_AES256 },
    { "AES256", USM_CREATE_USER_PRIV_AES256 },
    /** cisco / pysnmp variations */
    { "AES-192-C", USM_CREATE_USER_PRIV_AES192_CISCO },
    { "AES192C", USM_CREATE_USER_PRIV_AES192_CISCO },
    { "AES-256-C", USM_CREATE_USER_PRIV_AES256_CISCO },
    { "AES256C", USM_CREATE_USER_PRIV_AES256_CISCO },
#endif

Options available for command line are defined in net-snmp-5.8/include/net-snmp/library/transform_oids.h:

#ifdef NETSNMP_DRAFT_BLUMENTHAL_AES_04
NETSNMP_IMPORT oid      usmAES192PrivProtocol[9];
NETSNMP_IMPORT oid      usmAES256PrivProtocol[9];

NETSNMP_IMPORT oid      usmAES192CiscoPrivProtocol[11];
NETSNMP_IMPORT oid      usmAES256CiscoPrivProtocol[11];

NETSNMP_IMPORT oid      usmAES192Cisco2PrivProtocol[11];
NETSNMP_IMPORT oid      usmAES256Cisco2PrivProtocol[11];
#endif /* NETSNMP_DRAFT_BLUMENTHAL_AES_04 */

We can see that there basically are 2 "versions" of AES256: Cisco's and pre-RFC's.
Version for Cisco uses "C" as a suffix when use from command line.

I've prepared patch to test it (for zabbix 4.0). And it works, tested on Cisco virtual router.
Screenshots to demonstrate it are attached. One sample traffic capture with AES256C too.

Interesting that in Wireshark, when configuring SNMP user (to decrypt traffic), there is only one option "AES256" (without C), but it works exactly and only for Cisco's encryption. I.e. it does not work for pre-RFC mode.

Using "net-snmp-config --configure-options" we can see options net-snmp compiled with.
Unfortunately any Linux distro, which provide net-snmp v5.8 (CentOS8, Fedora 29-32), do not provide packages with "--enable-blumenthal-aes" option compiled in.
So, library requires recompilation, but that's still possible and I suppose that's just a question of time when it will be enabled by default.

Important detail that net-snmp version 5.8 bumped version for "soname" in library (30->35), so currently it's libnetsnmp.so.35, while v5.7 provided libnetsnmp.so.30

Note: if use zabbix server with the patch and use new modes, but dynamically loaded library does not support the new modes, host interface will become unavailable (red) with this error:

"Unsupported privacy protocol [3]"

In my patch I've added support only for Cisco's modes, and I feel it's reasonable and enough.
I don't thing that pre-RFC's modes are really used somewhere.