Real-time, devices likely answer the question of stationary or moving by comparing adjacent position solutions. Since these adjacent solutions will almost always indicate movement (i.e. not be identical), a threshold value of distance or speed (these are the same over a 1 sec interval) might be used to determine motion.
I would hope that the threshold is based on speed not distance and that the speed is averaged over several points to ensure an accurate estimate. Belt mounting might be a good option. I have also had WASS/EGNOS disabled so that is something else to try. I still think that better quality device firmware is required though: firmware that tells you that you are stopped when you really are stopped and moving when you really are moving. Obviously a walker's definition of stopped and moving is very much simpler than a software engineer's.
I assume that track log record method (auto/distance/time) has no effect at all on the trip computer. Mine is set to Auto.
I would also enable GLONASS if it's not already. It can help a lot if you are getting a poor signal.
Your choice for logging data will have no effect on the trip computer.
Older consumer gps receivers updated positions at 1/sec, so, if this is still true for Garmin handhelds, then distance and speed are the same value for a 1 sec interval (the programming will likely use units native to GPS calculations; meters for distance, seconds for time and m/s for speed). At faster intervals, calculation of speed may not be worth the cost. In BaseCamp/MapSoucre, speed along with the time interval between two logged points would be needed.
For the purpose of detecting motion, precision of measurement is more important than accuracy of measurement. That is to say we become more interested in point to point comparisons as opposed to point to true value comparisons. As the interval between solutions becomes small, the more similar the biased errors will be in magnitude and direction between adjacent points and the more point to point error will reflect the precision of measurement. At an update rate of 1 Hz or greater, averaging may not gain that much.
Under good conditions with WAAS/EGNOS, I think I saw stationary point to point variation of less than 1 foot over a 1 second interval 95% of the time based on a test I did some time ago with a different device. This would be about 0.7 mph (1.1 km/hr) – reasonable to cover most walkers and every activity that is faster. I have never run a test under poor conditions or without WAAS (my curiosity has its limits), so I can’t tell you how the limits change as conditions worsen.
Since you are seeing false stationary guesses at 3.5 mph it could be mean that you are loosing a good deal of accuracy by placing the device in your pocket along with Garmin using a table of values and needing to adjust these values for poor reception. Of course, it could also mean that Garmin uses some other means of detecting motion, which may be the more likely answer. My method is just the first I would try to implement without giving it too much thought.
Experiments you might consider are the same walk with the device in your hand and in your pocket in similar terrain/direction as your long walk. Also recording a track while stationary with the device in your pocket and on the north side of your body (someone south of the equator should have it on the south side of their body) under poor conditions (say under a forest canopy with a nearby hill/bluff to the south (to the north south of the equator). The last would give better idea of the magnitude of false motion while the device is actually stationary under poor condition.
Posting your results (1 sec interval track logs as a gpx file) might help the collective to get a better handle on what is happening.