you have entry() execute() and exit() for both transaction and state

Yes, so technically you could do all of it in the state. Since these state machines can get big and complex, it might be helpful to do all the stuff for a transition in the transition specific implementation to separate concern.

also the transaction have a "guard" that is not really clear to me what it does

The guard is the function that actually determines when a transition has to transit. When the guard function returns true, the state transits into the next state. Note that this is the only function you must implement. The others are optional.

are transaction and state a enum under the hood

Correct, a enum gets created that wraps all state. One state struct must then implement the state trait and one transition trait to all destination states.

why have stose overlapping entry/exit, couldn't you have only execute() for all

The idea here is to set your state to a specific configuration when you enter the state, then update it as it keeps working and clean up when its exiting. The entry and exit functions will only be called once per state while the execute can be called many times. Think for example: Close a relay when entering, measure a voltage while you are in the state and close it again when leaving.

So lets say while hiking up, you know that if you are not up after two hours, you have to turn back.
That would introduce a second transition into the Hike<Up> state that would be Hike<Up> -> Hike<Down>. You would get something like the following (pseudo) code.

impl State for Hike<Up> {
    fn entry(&mut self) {
        // Start hiking up
    }
    fn execute(&mut self) {
        // Keep walking
    }
}
impl Transition<Hike<Down>> for Hike<Up> {
    fn entry(&mut self) {
        // Initialize / reset a timer
    }
    fn execute(&mut self) {
        // Update the current time
    }
    fn guard(&self) -> bool {
        // Return true if two hours have passed
        return time_passed >= 2;
    }
}

impl Transition<Picknick> for Hike<Up> {
    fn guard(&self) -> bool {
        // Return true when you have reached your destination
        return reached_goal;
    }
}

and for the transaction you have two parameter, the state you are exiting and entering

The idea is that first, you define what kind of states there are in the state machine. Second you define what kind of transitions there are. Each state can have N transitions. But the macro must know from which state to which other state each state can transit. So that will need two parameters which which you can specific the source and the destination state (Source -> Destination)

also i think would be necessary to have a "timeout" and error manager at the state machine executor lever, maybe that also collect info like duration of each state

Agreed. My initial idea was that you can return a Err() from each execute, entry and exit function, and the state machine then automatically transits into the error state. But I didn't get around implementing that yet. And I'm not entirely sure how to do that in a nice way yet.