Thanks for the post!
I'll give the first of what I figure will be a long list of opinions. It seems like that's what you're looking for.
Possible? Yes. Pretty much anything I've considered is possible with FMP
Difficult? No, not really, but you'll want to pay attention along the way to strictly avoid calculation fields, summaries, etc.
Recommended? Well...it depends. how many times are you going to provide revisions, new features, etc.
What you propose to do (if I understand it well) is to use FMP as the database it is. I highly recommend it! If you want to simply avoid dependant calculations and store actual data in the field...yeah...I could see wanting to do that, I do that fairly often too...it avoids some headaches. But as far as separating data from structure...in what way are they intertwined in FMP? While there is tons of functionality available, it's all linked to scripts and layouts and triggers. Underneath there's just a big heap of data that isn't very hard to import or export.
Did I give a fitting answer, or miss your point utterly? I'm sometimes known for doing both simultaneously.
Well, avoiding calculations and summaries may be difficult. I have many in there now. The requirements of the user call for it... as the application involves financial matters, reports, etc.
This is an existing solution that I'd like to rewrite, for use by more users than the one it was developed for. History shows that there may be as many as a couple of enhancements ordered each year. I would plan to roll them up into aan annual "version-upgrade", build some scripting to perform the upgrade, and send it out. So, the export/import of existing data would have to be straight-forward, and as bullet-proof as possible, since I'm not likely to be the one doing it.
I have read and researched, not done.