Consistently Not Done, Done, Done at the End of Sprints?

Where is the link target?

I have observed that the less self-organized a team, which uses time-boxing, is, the more likely they will have significant amounts of started and uncompleted work at the end of the sprint. This is usually in the testing area. The counter-measure I most often use is to work with team on what the nature of commitment is and that they need to monitor and re-act when internal queuing of work occurs, by draining the queue before starting new work.

I have found that by increasing the visibility of the sprint work the team becomes more self-managing and quickly learns to adopt best practice. For example, a simple whiteboard board with the list of work, the person who has accepted doing the work, the business priority and the status of the work enables all team members to check that they are working on the highest priority and that they are only working on one thing at once. The other benefit of this is that all items which have an impediment are highly visible and help them to become the top of people's to do lists so that they get resolved faster. Thus overall decreasing the likelihood of items not being done at the end of the sprint.

I thought the whole point of time boxes was to have the must haves done and to drop some of the should and could haves. Considering you have typed the features in the time box by the MoSCoW rule and have a mix of those types in the time box.

In situation where everything is equally important, most commonly that everything is a must have and nothing can be dropped, there is no time box only a deadline.
In those cases the time box is just a formal way of having periodical checkups by management. Nothing wrong with that, but it's more efficient to know up front what management thinks is really important, so you can focus on those features and if you have some time left spend some on the less important once.

The important thing for any kind of planning should be doing the right thing for the customer and manage customer expectations. The more you meet with the customer and the more clear the demands, the progress made and the options to steer the better the result of the project.
Extending the boundaries of the time box because of things not being done is just silly, unless you can't get any work done because of all the meetings. Things consistently not being done is a sure sign of features not being small and detailed enough. Dividing them up will be more work for the planner and if that is something that is done by a coder he will complete less features and the project will actually produce less.
The 4 week sprints should be halved to the more regular 2. This will give the customer more feedback and more moments to steer the project.
By doing both you increase the feeling of the customer of being in control by introducing more overhead and thus be less efficient.
It depends on the type of client and the level of trust he has in your project how much control he wants. Normally clients want more control, but it could be that the client is internal to your organization is more concerned with efficiency and doesn't mind a few things not being done.