The other way to look at this is what deliverables are required/created when your company is doing a systems project. Is there a separation between requirements and solution? As a person who mainly does requirements, I have seen many different deliverables that come after requirements:  Technical Architecture, Functional Specification, External and Internal Design, you name it.

What does your company expect to see as a project proceeds? Typically, Business Analysts do Requirements, and Systems Analysts don't, but it depends on the company. I have seen shops were System Analysts take requirements and determine in which of the existing systems they will be met, often across multiple systems. Then it depends on if Systems Analysts are separate from designers and programmers, or if they do those jobs too. I have also seen shops where Systems Analysts aren't in projects, they are support experts for the company's existing systems. I have also seen where people who fit the above descriptions of a system analyst have the title Business Analyst.

So again, start with understanding what needs to be done, and then see who is doing it; job titles may be misleading.

Generally speaking, the Business Analyst is closer to the Business

The Systems Analyst is closer to the system ( more technically inclined, comes up with the Design, Solution)

The Business Systems Analyst is somewhere in between.

To answer some of the questions you raise, it all depends on the shop. I worked for a place where the Sr. Manager hated titles and encouraged staff to explore beyond their boundary box limitations.