1.4 is a good place to be starting - there's been a huge performance improvement, as well as significant simplification of HTML structure vs older releases. But, of course, you will have to live with some bugs for a while, as it's still only a release candidate. And you will not have to un-learn old stuff.
I note that you've created a "multi-page" document. I generally caution against this. However, at 3 pages, this is an appropriate-sized project for this layout. Please do not be tempted to build-out much beyond this size, though, as a multi-page. The multi-page layout does offer some advantages for a project of this size.
Projects tend to grow pages, though, and the more pages you create, then the more effort you will expend later converting the project. So, when you create a 3-page project using a multi-page document, make sure it isn't later going to turn into a 100-page (or even a 10-page) project.
You've included some scripting inline in the <head>. (For the player widget.) This has no particular impact in the case of a multi-page document, but it should be avoided if you do a project using single-page documents, since you will need to repeat everything in <head> on every page if it is a website or webapp, in order to support browser refresh, bookmarking, and deep linking from other sites. To avoid bloating the size of <head> (all of which, other than <title> is just ignored on all but the first page), then, it's better to always link to files instead of including the code inline.
You've used IDs. This is generally a bad idea in JQM. You have to be careful not to duplicate an ID on any two pages that might be in the DOM at the same time. It's hard to manage that. It's easy to look at a single document and see if there are any duplicate IDs. It's hard to insure that you have not duplicated an ID in an entire project. (Which, as a practical matter, is needed to insure you won't duplicate an ID on any two pages that might be in the DOM at the same time.) This can be a blind spot for developers used to having the document reload for each page. There's never any need to look beyond a single page for duplicates. Not so for JQM.
There are some rather non-obvious edge cases, where an ID can get you in trouble even if you have not duplicated it in two pages. (Example: same-page Ajax reload with transition.)
The ID problem in a nutshell can be described with a slight paraphrase of the odd GitHub 404 error message:
"This is not the element you are looking for"
If you have duplicates, which one do you get if you select on that ID? Well, usually (but not always) the first such ID in the document. But, varies by browser, and no guarantees, because it's invalid HTML with no standard that specifies what should happen.
But for a multi-page document, there should be no problem using IDs. They certainly make things easier when opening panels and popups. Otherwise, you need to write some JS code to open them using some other type of selector. (Typically, class selector.)
Similar to multi-page document structure, removing ID usage after a site has built-out can be a very labor-intensive rescue. So, best to get out of the habit, and use IDs very sparingly. The general approach I take is to use CSS classes instead, and always scope selectors to a particular page. I usually use a pageinit callback for a page or class of pages, and then within the callback search within the page to bind to buttons, etc.
IDs for pages can be OK if you are careful. For same-page transition, there would be an ID problem only for content inside of the page.
However, keep in mind just what a "unique page" is. If, for example, you have an album page, and you are going to have your server deliver a different page for each album, you can't have them all have ID album. You'd need to prepend/append some unique string to each. e.g. album12345. This can be painful. Of course, if you are using your own Ajax to load some data into a single album page, then that will be fine without the suffix.
I just find it is best to avoid IDs altogether, because they are not useful in most cases, and even when you think you are being careful, it is easy to get tripped-up.
I think Jake modified his example already, but I think there was a good example of an ID problem in it originally. The panels were repeated in two different pages. I don't know, though, if unique IDs were used. I was going to suggest an experiment:
Assuming the IDs were not unique, it would be a good demo of the problem. If the IDs were not unique, and because JQM 1.4 allows panels outside of the page (either outside of a page, or even in another page), when you bring up a panel from one of the links on page 2, you are really bringing up the panel embedded in page 1! The easy demo is to change some of the text in one of the panels on page 2. You would then see that when you bring up a panel from page 2, the text would not match.