If so, I assume the new types generate different bitcoin addresses based on the same(?) underlying private key (I am here assuming that Armory still generates a single chain of private keys. I guess that cannot have changed if it is still sufficient to back the old wallet file up).
A private key yields a unique public key, that public key can encapsulated in any variations of output scripts. The new scripts are just that, different ways to use a public key. The code still makes sure a public is used once, regardless of what script type it was used as.
Are the new ways of generating bitcoin addresses Armory-specific, or are they standardized?
There is no real standard to begin with. BIP32/44 assumes P2PKH but doesn't really distinguish between compressed and uncompressed public keys anyways.
The conclusion of the Berlin s3nd meet was that we (wallet/service providers) are better off enforcing incompatibility than to try to get things done under one standard, as it just won't fit all use cases.
I am asking because who knows what will happen to the Armory project in the future. At some point it may be discontinued, or the blockchain may become so big that I can no longer run Bitcoin Core. It gives me peace of mind that I can always run Armory in a tiny virtual environment and extract the private keys to another wallet. But that of course requires that the other wallet can generate the same kinds of output.
The 2 script types you can expect other wallets to support are P2PKH and P2SH-P2WPKH. As for running Armory in a restricted environment, I have ideas to reduce the requirements (like running off of a pruned node), but they aren't priorities atm.
