yeah, that's basically correct - how you should proceed is mainly determined by your requirements/goals - for instance, JSBSim involves XML and possibly C++ level changes - property rules/ap stuff is generally pretty flexible but also somewhat restricted, Nasal is fairly flexible but generally frame-rate/garbage-collection bound, so may affect frame-spacing and frame rate of the fg main loop. External interfacing works pretty well but isn't as integrated obviously, and bring a certain setup overhead with it, too.
People intimately familiar with JSBSim and its concepts (or with a strong background in control theory and aerodynamics), will usually want to use JSBSim.
People with a "tinkering mentality" should be just fine using Nasal, replacing performance-critical stuff with XML-based PropertyRules.
External interfacing (matlab etc) is usually used by professional/proprietary projects that may need to work with closed-source code/data.
The latter is usually also used for hooking up external plotting tools to fgfs for visualization purposes.
If you're looking for a totally integrated solution, Nasal/Canvas is offering a ton of possibilities, as can be seen by fgplot:
http://wiki.flightgear.org/FGPlotIn addition, there are some hard-coded restrictions affecting if/how certain solutions may be feasible/appropriate - but the details will heavily depend on your concrete use-case/scenario.
JSBSim stuff generally works great and it's a fairly accessible code-base, too - so can be easily extended by people familiar with C++ - and extending JSBSim also doesn't necessarily involve building FlightGear from source, so is pretty straightforward (fgfs can use jsbsim in "external fdm" mode).
Rebuilding fgfs from source is a completely different challenge - but once you've got a working build environment, it's hard to beat the degree of integration offered by using built-in means (PropertyRules, Nasal, Canvas, I/O etc).