You have a serious but small issue, and a serious but large issue. Both come down to a need to train your manager in prioritizing, by carefully explaining how not doing so is defeating the achievement of their goals even more than how it is ruining your life.
Early AM Email
With specific regard to the early am email, because email is asynchronous people tend to send it in a response to their thoughts, but if it is routinely disrupting your thoughts and your sleep, you'll need to explain this and work out a more productive arrangement. There are basically two choices:
Ask your manager to use delayed email send, either as a software feature or a personal habit. If their requests hit your inbox as your are waking up, then you can either read them when you get in, or read them before your commute and have that time to think productively about them - rather than lose a night's sleep over your manager's latest "we should ..." brainstorm.
Or you can stop reading email late at night. The downside for this to gently make clear is that it means that you are harder to reach in a true emergency. Perhaps you can work out something with a magic priority keyword and a filter, or a second email address that does go to your phone while the primary goes only to a computer. If routine things still end up being sent via the emergency channel, then that has to be treated as a routine channel as well, and there cannot be a priority one.
Some might say that you should train yourself to mentally filter these requests - and perhaps to some degree you can and should. But that is effectively a form of strategic disengagement, already contrary to the kind of fully engaged thinking that leads to doing one's best technical work, and thus if taken very far potentially already the beginning of the end of your tenure in this role. Instead, you really want to be in the situation where if your manager asks you for something, you can give it serious consideration - and that is only possible if they also exercise some care with regard to what they ask, with what tone of expectation, and when.
Task Priorities for the Team
It sounds like your manager keeps making new requests which supersede their in-progress ones, and this is of course the much larger issue. In large part, this is the problem that current project management schemes and tools seek to solve by formalized process. Some variation of such a process may or may not fit your organization - but what is fundamentally key to them is communication of status, needs, and their cost.
Ideally, you'd start each day with a brief meeting, with both your manager and your team, either together or separately in whatever order best fits your situation.
Your agenda would be something like:
What is being worked on, and how it is going
What new concerns have arisen (cover first if sufficiently urgent)
What would be the cost of switching task
Decisions
Resume work
Once that has set the sense of an ordinary day's work, if there are extraordinary things to consider, you can periodically or when necessary break that out into a more in-depth discussion of strategy and planning.
Most formalized systems have some sort of record keeping - stories, issue database, post-it notes on the whiteboard. Much of the purpose of this is concerned with keeping track of what is not being worked on, and thus a lot of its role in your situation would be the growing backlog of things which have fallen by the wayside as they are displaced by new requests. Talking through these with your manager periodically will be key to how you help them learn to balance priorities.
The above is a lot more general and discretionary than many project management schemes, which propose strict rules for planning, scheduling, and changing tasks. Essentially, rules exist for situations where a sense of sound judgement cannot be found - either between parities or even in the sense of one person's own long terms goals vs. momentary discipline. The more you can trust each other's common understanding the more flexible you can be, the more you cannot find common understanding, the more rigid your process needs to be.
Two Week Sprint
This is of course the classic example in today's thinking of a formalized planning tool.
On the plus side:
it tries to strike a balance between sticking with a task long enough to complete it, vs. diving so deeply into one concern that others are lost
it teaches the skill of breaking large problems up into approachable chunks
it provides a proper path for introducing new requests without undue interruption
it attempts to educate on organizing and prioritizing requests
a decision to depart from the plan becomes an explicit and explicitly recorded one
On the down side:
insufficient agility to respond to many rapidly evolving real world situations where what you've ended up needing to do looks nothing like what you though you would at the start
it poorly matches exploratory tasks of yet unknown scope
breaking large tasks with complex interdependency into small pieces (and especially doing so before beginning) may introduce arbitrary divisions leading to fractured thought and code
it discourages initiative to pursue newer, better ideas or fix longstanding problems under the powerful motivation of being fed up with the workaround that's been being used
But those are of course only a few of the pages and years of arguments that could be made for or against this or any other mechanism. Ultimately it is up to you and your manager to decide if a more formalized system may help your organization learn to better manage your team's work or if you can find your own more dynamic, flexible, and efficient understanding. The more you agree the more flexible you can be; the more you fail to reach a common understanding, the more you'll need a structured process to manage your differences.
