If it's a stack I already know I genuinely can't tolerate, I'd immediately start looking for work elsewhere.
Otherwise, I'd give it a chance. Learning new (to you, not necessarily new to the industry) things is a joy, it adds another skill to your skillset, and makes you a better and more employable dev. Even if the new-to-you thing is old and/or not popular. Actually, not being popular can make it even more valuable as there would be fewer devs familiar with the stack.
But let me admit my bias: my worst nightmare is a job where I'm just using the same skills over and over. I've quit jobs because of that. So, personally, having to learn new things is something that makes a job more desirable to me, not less.
Assuming I don't know or like this tech stack, on top of the fact that it doesn't open up any potential employment opportunities, I probably would start looking for a different job with a stack that I am familiar with and/or enjoy working with. If my company changed the stack, and if I didn't know if I like the new stack or not, I would probably stick around at least for a little bit, changing the technology you work with isn't always a bad idea, and can give you a wider range of experience.
I'd give it a shot just to try it out and see how I like it. If I didn't like it, I'd try to understand why – what are the pros and cons of that approach vs the ones I'm familiar with – before tossing it out altogether. Once I feel I have a solid enough understanding of why the stack is that why, then I can decide whether to embrace it for what it is, or otherwise to then leave that team/company.
A few times, I've been exposed to new stacks I didn't really like.
One was Drupal, coming from the Wordpress world. That was a real nightmare. I learned it enough to work with it, started an upgrade/rewrite to a new major version (not backward compatible), and then convinced my bosses it's not a good choice for us. I rewrote the whole thing in React/Next and cut away thousands of lines of code and config. Drupal is the only framework I swore to myself I would NEVER work with again. The rest of the LEMP stack isn't my favorite, but it's fine.
The other was Java. We had a web app written in React, with unit tests written in the usual Javascript frameworks and living alongside everything else. Then a new outsourced manager came in with a Java background and insisted we rewrite all the frontend tests in Java because that's what the backend was written in (still makes no sense to me). He hired other people from his country who also knew Java. It took more than a year to port over some tiny fraction of the tests, and we lost a bunch in the process. The Java testing framework they set up was kinda a hot mess, with machine-to-machine incompatibilities, issues with hardcoded paths, etc. And you could no longer run them with `npm test` in the repo, instead needing a whole container or VM just to start the Java env in which the tests would run. They took 100 times longer. The tests went from being our shared responsibility (that any web dev could maintain) to something only the one QA person he hired could write – but they weren't very familiar with HTML or CSS or Xpath. I had to learn just enough Java to help them debug their own tests and Java setups, in the process coming to dislike it (it's quite bloated and archaic compared to the modern JS DX). I didn't hate it, but it wouldn't be my first choice for a project. It did make me interested in Kotlin and (less related) Rust, though. I left that company soon after, due to that and other recurring incidents of poor management.
----------
Too bad there's not a tech skill-swap system. Got a project you don't like? Wish you were working in a different language? Find someone in the opposite situation to trade with! A few NDAs and some time tracking later, everyone walks away happy...?
No. I am platform agnostic.