Moved /bin contents to /usr/bin, possible to undo?

On Linux (and on most other systems, though POSIX doesn't give you that guarantee unless the move was across file systems), that would have updated their ctime, so assuming none of the other ones in /usr/bin have been touched in the last 24 hours, you should be able to move them back with:

find /usr/bin/. ! -name . -prune -ctime -1 -exec sh -c '
   echo mv -i "$@" /bin' sh {} +

Remove the echo if that looks right. Note that you won't be able to recover the files that existed by the same name in /bin and /usr/bin (the original ones in /usr/bin would have been lost)

A potential caveat: if some files were hard linked in both /bin and /usr/bin, all the hard links in /usr/bin would be moved to /bin.

Now, you may think that since /bin and /usr/bin are in the default $PATH, and /bin is available on /boot at least before /usr is mounted, it should not matter whether the executables are in /bin instead of /usr/bin.

But that would be overlooking that many commands hard code the paths of executables and expect them to be in some specific case. A common case is she-bangs. All scripts that have:

#! /usr/bin/env bash

will fail to work after you do mv /usr/bin/env /bin/env. In that regard, having the commands in both locations is safer in that it won't break those scripts.

Is my Ubuntu in a broken state now?

Yes, your Ubuntu is broken

You messed up something important to package management.

So in practice, backup your important data (at least /etc and /home), perhaps also the list of installed packages e.g. output of dpkg -l, and reinstall Ubuntu.

^{(a non-novice could try to manage - like in other answers -, but then he would not have done such a huge and basic mistake)}

I could just admit to screwup reinstall the whole linux partition.

That is probably what would consume less of your time. Keeping your current system with the help of other answers is keeping it in a very messy state (which would give you future headaches).

Since you are reformatting your disk, consider putting /home in a separate partition (so future such mistakes won't lose your data). Before doing that print on paper the output of df -h and df -hi and fdisk -l (they give information about disk space -both used and available- ...). Be wise to have a large enough system partition (the root file system); if you can afford it 100 Gbytes is more than enough.

I was supposed to move the software bin -folder contents to /usr/bin

(terminology: Unix have directories, not "folders").

That (moving to /usr/bin/) is very wrong. Either improve your $PATH (preferably) or at most add symlinks in /usr/bin/ and preferably move (or add symlinks) executables to /usr/local/bin/.

The wise approach is to never change /usr/bin/, /bin, /sbin, /usr/sbin/ outside of package management tools (e.g. dpkg, apt-get, aptitude, etc...). Read the FHS.

1. Your installation should be mostly OK; there shouldn’t be different files with the same name in /usr and /usr/bin (which answers your 2.1), so having all the files in both /bin and /usr/bin won’t break anything (until you upgrade packages). The only problem you might have now is broken symlinks, if you overwrote a binary with a symlink to it. To fix this, look for broken symlinks:

   find -L /bin /usr/bin -type l -ls
   

   and reinstall any packages corresponding to the files listed (for example, if /usr/bin/zsh shows up as broken, dpkg -S /bin/zsh /usr/bin/zsh will tell you which package the file came from; reinstall it with apt --reinstall install zsh).

2. You can show and sort by ctime to see files which were recently changed (which will include files you moved):

   ls -ltc /bin
   

3. The best approach to undo what you did is use the cruft package and delete files it finds in /bin or /usr/bin which don’t come from a package:

   sudo apt install cruft
   sudo cruft -d "/ /usr"
   

   unless the files are symlinks to files in /etc/alternatives (in which case you should leave them alone).