I'm not sure there is benefit differentiating preview open file (with italic font) from fully opened files. What information does this give the user and how would they act on it?
Italics in the heading doesn't look good on some lower resolution monitors.

@gregvanl see https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/June_2016.md#preview-editors
We do this so that users aren't surprised when the content of a file they are looking at is replaced with the content of a new file that they single click on. We think that we need to distinguish these files. Doing so is a common pattern - Sublime Text italicizes these files and Visual Studio positions them to the far right of the document well. Knowing that a file is open in a preview tab would then let the user know that if they want to keep it open they have to take another action (the keep open action).
One question is whether or not italics is the best way to communicate this to users. A challenge we have though is that we don't want this to require significant UI management or overhead. We do not want to distract the user from focusing on their content.
One last update: Greg and I verified that the bad italic screenshot above was due to ClearType not being enabled by default on Windows Server 2008 (the OS he was using).
Enabling ClearType fixed the problem immediately. On this particular OS, you must enable it manually, probably because it's not a typical desktop machine but is meant to be tuned for server performance.
I don't think this will be a common scenario. We should be fine with continuing with italic usage, and since it's a pattern used elsewhere, I think it's appropriate.
@stevencl are there a way to never open "italic" file window (I open file by cmd+p shortcut, so no way to double click)? I find the "italic" file window annoying because in most of the time I would like the window I opened stay there. And I close what I want to close manually. Thanks!
"workbench.editor.enablePreview": false
@bpasero THANKKK YOUUUUU. I loathe this feature in Visual Studio, and equally as much as VSCode. If I had to choose a single setting to put in my user settings, this would be it. Nothing more infuriating than code files closing when I click somewhere else. I don't mind inline preview windows (the idea of previewing is definitely powerful), but having "preview" tabs that disappear is one of the worst/most unintuitive UI decisions ever made by the Visual Studio team (or whatever other application they borrowed the idea from).
That said, making every setting easily overridable via one big, searchable text file is easily one of the best decisions ever made because it totally negates all of my hostility toward settings I don't like. 馃憤
Note to others seeing this: the keybind workbench.action.keepEditor allows you to convert a preview editor to a main editor. If your workflow requires you to dig deep into codebases (e.g. following chains of definitions) and you want to save your current point as a tab before moving into the next file WITHOUT having a tab for every file you touch in the chain, keeping previews on but committing that keybind to memory is an excellent sanity saver.
Most helpful comment
"workbench.editor.enablePreview": false