Shoot, I forgot to wear green.

Alright, this is going to be a lot... #oopz

═══════════════════════════════════

❶  Its not very sophisticated to have the stroke weight in glyphs like lowercase (a) and (e)'s horizontals to be only 75% of a font's default stroke weight.
— The (partially-) and/or enclosed verticals could be adjusted when compensation for ever shrinking negative whitespace area in places such as counters, in bold small grid fontstructions. Or in the case of your font, any other horizontal stroke in a glyph's general mid-section for letters (AaBbEeFfGgHhKkPpRrSstXxY).
Commit to a SINGLE, yet CLEVER solution that can solve ALL the various troubled areas your ENTIRE character set. Even to mix just two methods in this process usually causing only new irregularities elsewhere, if not simply creating just more than you initially started with. Its allowed to mirror/flip (not rotate) the implimentation for your compensation adjustment. But important to keep in mind is, modifying a specific element (lets say the crossbar) in one glyph, means you have to do the crossbars in EVERY glyph. So, Its either all, or nothing at all. Although minute variation to these adjusted crossbar-weights is allowed, as far as small grid fonts in FontStruct go, making such small adjusments is very difficult or even impossible.
Rules of thumb here is that there shouldn't be any obvious optical difference taken from a quick glance. So, try to keep them approximately the same thickness. Some a slight difference between the adjustments applied to the upper- and lowercase sets is allowed, but rather prefered not of course. And if for whatever reason, this still is absolutely necessary, its obvious that the modifications implemented are kept consistently for each of the two seporate character sets.
❷  The vertical bar (|) and broken bar (¦) can (and often are) designed a “tad bit” thinner than the font's default stroke weight. But not as thin as you did yours, and this is certainly too much.
❸  Mentioned in ❷ especially applies for your currency sign (¤) and trademark symbol (™). These are even more important since these glyphs already are smaller than the default glyph size. So when the font is scaled down, these could become ever smaller, untill at some point for the smallest readable font size renderings, they become too small for rasterization process to even turn on a single pixel at all, hence, will render it invissible. So, in other words, simply will display the glyph to appear as an empty white space character.
❹  The Asterisk (*) is best aligned with the cap-height of the font. Also, big and visible design is fine. But bigger than a full lowercase glyph's circumference?
❺  Capital letter (G)’s horizontal bar is, how should I say this clear, “beyond skinny” probably.. This once more, should be approximately the same weight as the other horizontal letter-elements in your font.
❻  Funny is that you take the overal approach of overcompensating your various letter-parts and other type elements but you leave lowercase letter (k) and (x)'s horizontal parts, as well as numeral (8)'s spine unchecked, leaving them at full weight. These should also follow the same algorithm for your correction interpolarization.
❼  Numeral (4) has this (kind-of) weird looking, condensed style, that isn't consistent with the other numeral forms.
❽  Numeral (7)'s leg is slightly too thin, and should be roughly equal to the default weight.
❾  The horizontal parts that make up the stroke-intersections for letters (KkXx) wasn't adjusted either. Again, making compensations in one glyph means doing this for all glyphs.

❿  The mid-sections for characters (KkXx) were constructed with the use of this “double quarter-circle tangent” brick to make the section where the top upward sloping and lower downward sloping strokes meet to intersect. The tangent isn't cut very deep into the inner-glyph's body, for both capital letter (B) and numerals (3) and (8) this was done slightly better, but still this could be done much more pronounced. This will drastically improve your font in smaller point size rendering.

═══════════════════════════════════

I fully understand that there are always trade-offs to be made, and even more so when fonts are build in FontStruct. But my advice is that you should try and avoid to basically just creating additional new distractions within your font's character set. Keep all your adjustments relative to each and one another, as well as applying them proportionally will make sure you maintain consistency.

═══════════════════════════════════

Here is some indirect but still relative little side-knowledge in terms of FontStruct's visual feedback you get from the website's font generation module (FontMortar).

Fonts viewed in the FontStruct-editor, especially the smaller grid designs with bold weight-to-height ratios tend to look an overly congested and clogged appearence compared to what they will look like in a TrueType-font rasterization. Reason is that FontStructions are stored in a proprietary format, as they are frequently being edited, therefor aren't readily available as TrueType (*.TTF) fonts for rendering. So the glyphs you see in FontStruct, are in fact *.PNG images, rendered from the FontStruct-editor's canvas “actual” brick-content. It is very difficult to clean and accurately interpolate between the many different rasterization scales for a font at every given type size and resolution. Therefor the output quality for preview rendering varies for every scaled value. I'm not fully sure, but I suspect that for FontStruct's font gallery previews a different, more complex method is used to generate a font's canvas rendering. Since these show vastely improved and reliable output quality compared to those inside the editor itself.

So, be careful not to let the FontStruct website's font rendering play tricks on your mind, making you wan't to overcompensate for what you see while using the website.

═══════════════════════════════════

My apologies for taking an entire day's worth of your time with this encyclopedia-worth of information.