1.6.1 is a minor release, and as such should not break anything you’re doing. On the other hand it can happen that packages drop compatibility to older Julia versions (as a newer version introduced some feature that the package author wants to leverage), which then restricts you to an older version of the package which is compatible with the outdated Julia version you’re using.
I’d say give it a try - the balance of risk and reward is in my opinion quite heavily skewed to the reward side here, plut you’re not really losing anything as it probably only takes half an hour to install Julia 1.6.1 alongside your current version and test drive your code in it!
Also apart from that, I would not refer to a new environment as a “nuclear option”, on the contrary it should be your preferred way of working in Julia. Your posts above suggest that you are working in the default environment (@v1.4), which is not recommended. It massively increases the risk of the kind of dependency conflicts you are experiencing, as you are forcing all packages you’re using (even if you never use them together on the same piece of code) to be compatible with another. It also makes it harder to keep your work reproducible - if you write some code which depends on packages in your default environment, it’s very hard to get it to run again a year later when your default environment has moved on. If instead you’d use an environment, then the code would use more or less exactly (depending on whether you rely on the Project.toml or Manifest.toml) the versions of all packages that you used whenever you last updated packages in that specific environment.
I started a recent thread about this here: Should we have a package update PSA? as I think this is an underappreciated aspect of the Julia workflow for many people.