As explained in that other answer, for password "encryption", the algorithm is usually part of the "encrypted password". And even if it is not, unless the algorithm has a secret key (called pepper in that context) or an otherwise secret component, password verification is deterministic, thus a known password and matching "encrypted password" allows to confirm or infirm a guess of the algorithm with near certainty (chosen password is not even needed).
Thus the answer to
Using their chosen plaintext and encrypted passwords, could an attacker determine what type of encryption was used?
is: yes if the "type of encryption" is among a list of candidates and uses no secret component (no pepper/key); likely no otherwise, unless of course headers or size considerations allow to narrow down the list of candidates.
Note: password "encryption" might not be worth the name encryption, because for any half-decent method there is intentionally no decryption procedure beside trying all passwords. At least, password "encryption" is not performed with a cipher. Common terminology is not "encrypted password", but hashed password or password hash. And even that is somewhat misleading, since hashing a password with a standard secure cryptographic hash function is not a secure way to compute a password hash. We want a special hash intended for passwords (entropy-stretching or password-based key derivation), and that needs extra inputs beyond the password: random salt, perhaps secret pepper, and parameter(s) controlling the work involved (number of iterations, and for modern methods amount of memory, number of threads..).
The question's title makes no reference to password, and it seems to be for a cipher (at least that's how it sounds on CSE).
If an attacker has a chosen-plaintext and encrypted data, can they determine the encryption type?
The answer to that is no, for common modern symmetric ciphers with unknown key, and unless the encryption type is apparent from non-encrypted data (which is common for interoperability reason; also, the habit of putting the date/time before the ciphertext could be a telltale sign). That's because common modern symmetric ciphers have their ciphertext essentially undistinguishable from random data of the same length, for one without the secret key. This in turn is because that's the best and most common way to be secure under Chosen Plaintext Attack while making the ciphertext as compact as possible (as compact as the plaintext within essentially constant overhead). The only thing an adversary could probably determine is the block width for algorithms where there is one (such as a block cipher in CBC mode), by observing the relation between plaintext length and ciphertext length.
If the algorithm's secret key leaks, then a guess of the algorithm can be checked. And some symmetric algorithms can be guessed; but that's a sign of insecurity or non-optimality, and standard algorithms are not of that kind.
Things are different for asymmetric encryption algorithms. For many common ones (including RSA), it is possible to recognize the algorithm from the ciphertext, especially with the public key known (and as the name implies, that is assumed known to all). Essentially, that's because asymmetric encryption algorithms do not try to have their ciphertext indistinguishable from random or/and as compact as possible, and thus leak identifying information (even when they are secure under CPA, a desirable and common goal). For some algorithms, known or chosen plaintext may help.
Note: Determining the algorithm is out of scope of modern cryptography, which assumes that the algorithm is public, by the second Kerckhoffs principle. Thus the question's topicality on CSE is debatable.