> check that a handle is actually a real console handle or 
> what type it is

Did you mean a path here? Certainly you can check a handle, but that means opening the path twice.

You can use GetFullPathName to classify the path, and then use GetFullPathName again when opening it. Keep the original path as the `name`. When classifying the path, ignore the DOS-device prefix, "\\.\" or "\\?\", if present, and do a case-insensitive match for CON, CONIN$, or CONOUT$.

GetFullPathName transforms paths containing the "CON" device, e.g. "C:\Temp\con   :.spam  " =>  "\\.\CON". This ignores trailing spaces and anything after the first "." or ":" in the last component. It also translates forward slashes, e.g. "//./con" => "\\.\con". On Windows 8+ it also works with CONIN$ and CONOUT$, transforming them to "\\.\CONIN$" and "\\.\CONOUT$". 

This is reliable on Windows 8+, without having to also call GetFullPathName again when opening the path. The problem with Windows Vista and 7 is a speed hack it has. In these older versions, opening the console has to be handled specially by the function OpenConsoleW, so like you have to do here, in Windows 7 there's an internal BaseIsThisAConsoleName function to classify a path. 

This function always checks for "CON", "CONIN$", or "CONOUT$" (case insensitive). But it also matches "\\.\CON" and in some cases also "CON" in the last component. Since BaseIsThisAConsoleName always has to be called, the path search could hurt performance. So there's a dubious hack to only look for "CON" if the path starts with "\", "c", or "C" or ends with "n", "N", "or ":". Thus "C:\temp\con  " opens the console because it starts with "C", but not "Z:\temp\con  " because it starts with "Z" and ends with a space.