My solution allows you to "manually unenroll a single user from a single course" as you asked, so if a user is in a cohort enrolled in a course and you need to unenroll the user from a course, swap the method to manual, take then from the cohort, then you can unenroll them from the manual method to get them out of the course, leaving all the other cohort members still enrolled as before.
Now, for sure, this is a method for an exceptional use case, though. It may do what you need in some situations. For example, if you have to leave the user in the cohort to keep them enrolled in other courses and just get them out of one, then this method won't work, you need another way to do it.
These are the pros and cons of cohorts: basically it works as designed if ALL the users will take ALL the same courses. Otherwise, problems will always arise if you have exceptional cases you need to manage one by one or group by group.
Some potential ways around this are 1) to have several different cohorts that overlap, so perhaps a master cohort of all users and some subset cohorts for the subset or odd or exceptional cases, in which case, you have to plan your cohorts carefully; or 2) you can use another mass enrollment method such as file upload
to do manual work, or external enrollments, etc. I see people do both of these but usually if you have a lot of Cohorts that are working okay, then making "sub-cohorts" to handle exceptional cases is a good way to go.
There is nothing wrong technically with mixing and matching and swapping enrollment methods to help solve such one off problems. It is more a matter of your sanity as an admin and keeping track of things as to how you do it: if you have to do this once a month and swap users around to/from cohorts/manually, no problem. If you have to do this every hour, then Cohorts perhaps are not the best method to match how your enrollments are really working, when your exceptions are more common than you think.