Warning: the following text is all gobblegobblegobble. Thank you for flying!
First, another vote for Strict. If you are creating a new web page, there is no reason to use anything other than strict. This is for YOUR benefit, though, not the browser's.
This is because browsers do very little with doctypes. In fact, a browser will only ever do one thing with your doctype: check to see if your doctype indicates that your web page was written in the 1990s or modern times. This is because browser vendors found it convenient to use the state of your doctype to decide if they should use outdated CSS rules when displaying the page or not. This is called "doctype switching." It's clever, and a bit silly.
The "new" so-called HTML5 doctype ( <!doctype html> ) is considered "standard" by all the user agents you care about, so this counts as a "modern" doctype. You may safely use it if you've been thinking of it.
So what's a doctype for, and why does it matter if it's just for doctype switching? It's for YOU. It's for the HTML validator(s), which is a tool useful to YOU as a developer. The validator helps check if your document is following the rules proposed by your chosen doctype.
Adding a meta tag will not (necessarily) set what how your document is read. You can make a meta tag saying
<meta http-equiv="content-type" content="foo/bar; charset=blah">
and you could still have flowers and puppies.
This is because unless your server serving the page isn't telling the browser what the page is, browsers ignore this line (same with the charset: if the server is setting the charset in a header, the browser can and will ignore the meta tag, because the server has precedence).
The reason you don't put gobbeldygook in that tag is because what if the server ISN'T sending the right MIME type? Then you're in trouble. Supposedly, if "foo/bar" or even "foo" is not understood, the agent isn't supposed to even try to display the information at all. It should give a MIME type error.
If you have "text/foo", then the agent can fall back to "text/plain" if it has to. If it does, you'll see the HTML tags on the screen
And lastly this is why even if you wanted to serve a page as XHTML, first the server would have to send the correct MIME type, and if it didn't and you used
any user agent who doesn't understand that can and will fall back to text/plain. Which you don't want.
Instead you'd have type="application/xhtml+xml" and here, the agent should understand "application" is something that's not text, and if it doesn't understand "xhtml" it can fall back to "xml" which often still does what you want.
Using an XHTML strict doctype and a meta tag stating this document is application/xhtml+xml served from a server who sends along the HTTP Header stating the document is really text/html, then what you have... is an HTML document with a bunch of silly slashes, which are considered errors, and ignored. Weee....
What felgall said about how scripts work in real XHTML... they've made even more changes if you are using XHTML5 (so far as I can gather, you have XHTML5 if you are sending application/xhtml+xml to a user agent who has an HTML5 parser). It will parse the page as XHTML using some of the new rules added to XML and XHTML. I tried to read what those differences were but me engrish not bestest there.