If your font has a FontSpecific encoding, there are no unexpected consequences; the same glyphs will show up at the same locations in both Windows (Win-OS/2) and native OS/2. Regardless of what the active code page is, if the font has a FontSpecific encoding OS/2 goes by cell value; a specific glyph is hard-coded to a specific cell and OS/2 will give you whatever it finds there, even if what it finds disagrees with what the active code page would normally predict. In other words, FontSpecific encoding means "ignore the mapping of the active code page and rely on the mapping hard-coded into the font instead."
If your font has an AdobeStandardEncoding encoding, the following details obtain:
1) The same PFB file may have glyphs that are accessible in one environment but not another. For example, if DeScribe thinks it is operating in CP 850, there is no access to typographic quotes, even if those do occur in the PFB file and even if Windows can find them in the same exact font file. DeScribe could switch code pages, but if the application isn't set up to do so (and DeScribe currently isn't), those characters are absolutely inaccessible to the user.
2) If the active code page includes a character that isn't present in the font, OS/2 has to improvise. For example, AdobeStandardEncoding fonts do not normally include the IBM pseudographics, yet the user who inputs the character value for one of these sends the system off to look for it. As described above, OS/2 first checks the active font for the glyph name that corresponds to that character and, if it finds it, displays it. If the glyph isn't found, OS/2 looks to the system Symbol font. This is not reported back to the user in DeScribe; if I have Adobe Minion active (AdobeStandardEncoding, no information anywhere in the font files for pseudographics) and input a pseudographic character, DeScribe tells me it is still using Adobe Minion, even though it has fetched the character it displays and prints from the Symbol font, a different font resource file.