Nice work. However, I have a question about the intended use : is it supposed to be a combat card, or a general purpose card ?
Because I can't see the need for a GP card - I mean, there's time to peruse the actual book when preparing a session, you don't really need cards for that. OTOH, having the database itself might be more useful than flipping through the pages of the various C&Ts. And you're probably missing information for that since the old C&Ts were notoriously spotty on some details (compared to, say, such books as the original IK Monsternomicon).
However, if it is a Combat Help card, then the fluff text is not needed - what is needed is a text explaining the overall demeanor (aggressive, cautious...), the attack modes and typical behaviour in conflict, but that's all. An illustration would probably be useful, but mostly to highlight the general form and size of the creature - so having a top view and side view with a scale would probably be more helpful. And that could make for a smaller card, which is interesting since space behind he GM screen is at a premium.
It's a wonderful insight, and I can't thank you enough. My goal has always been for a
supplemental Combat card, and that's how I wrote up my goals. And as you point out, my layout certainly implies more of a reference card than a combat card. Those are certainly two different things, and the layout should not confuse the two. Thinking back, I'd place the blame for the confusion at the feet of Special attacks. They, as written, tell the GM to refer to the text for further explanation. That's probably where I thought (improperly) "just pull the description"; I needed it for the Special Attacks after all.
What I
should have done was create a new section for Special Attacks, listing the pertinent information there and referencing it in the Attack. However, that's a MUCH larger undertaking, requiring a more sophisticated approach with respect to data storage, data transcription and textual parsing. Firstly each creature could have multiple special references, requiring a data storage approach to facilitate that (Foreign Keys in SQL parlance). Then each special attack would need to be located, and properly described up front, which isn't something that could be done programmatically. Then the textual description processing would need to be able to link those special attacks with the right special attack, for each attack the creature has. Lastly, all that data would have to be restructured in a flat spreadsheet so that the Deck printing tools I've considered (NanDeck and Component.Studio) could access the data.
I think I need a hard cider....
And yes, the older product creature descriptions can be quite 'spotty'. I'm thinking of things like 'Binlore' (*) or the even less detailed "Red Skeleton".
I realise that doing this requires much more effort and probably also requires professional-level illustration skills, and as such is out of scope of your work... but I'm taking the opportunity to share my thoughts on the general topic 
Don't you dare; no second guessing.
I asked for opinions, and you properly highlighted several critical ones to consider.
As far as the size of the card goes, a smaller card is certainly well worth considering. My initial qualm's at that were legibility at a smaller size, and the amount of information required. Subsequent to this post (and on Reddit), someone pointed me to the 5E products this company
https://www.evanandcolin.com/ recently successfully kickstarted. I found it quite interesting that they chose 4x6 card sizes.
Your insights (and others) have given me a great deal to think about, and my concept of design has already improved. Thank you.
(*) In RMSS/RMFRP the complete description consists of "A Binlore has the body of a bat, but the head of a Troll"; that's it. 'Red Skeleton' (and a few others) have no description at all.
