以下のような親digと子dig1・2を用意し、親から子をcallした場合とincludeした場合とでそれぞれでexport/storeした変数の可視範囲を調べてみた

parent.dig

_export:
  parent_export_var_1: parent_export_var_1_value
  parent_export_var_2: parent_export_var_2_value
  parent_export_var_3: parent_export_var_3_value
  rb:
    require: store_var.rb

+store1:
  rb>: StoreVar.store_var
  name:  parent_store_var_4
  value: parent_store_var_4_value

+child_call:
  call>: child_call.dig

+env1:
  sh>: env | grep _var_ | grep -v _command= | sort

+store2:
  rb>: StoreVar.store_var
  name:  parent_store_var_5
  value: parent_store_var_5_value

!include : child_include.dig

+env2:
  sh>: env | grep _var_ | grep -v _command= | sort

+store3:
  rb>: StoreVar.store_var
  name:  parent_store_var_6
  value: parent_store_var_6_value

child_call.dig

_export:
  parent_export_var_1: parent_export_var_1_value_override_by_child_call_export
  child_call_export_var_1: child_call_export_var_1_value
  rb:
    require: store_var.rb

+store1:
  rb>: StoreVar.store_var
  name:  child_call_store_var_2
  value: child_call_store_var_2_value

+env1:
  sh>: env | grep _var_ | grep -v _command= | sort

child_include.dig

_export:
  parent_export_var_2: parent_export_var_2_value_override_by_child_include_export
  child_include_export_var_1: child_include_export_var_1_value
  rb:
    require: store_var.rb

+store:
  rb>: StoreVar.store_var
  name:  child_include_store_var_2
  value: child_include_store_var_2_value

+env:
  sh>: env | grep _var_ | grep -v _command= | sort

store_var.rb

class StoreVar
  def store_var(name, value)
    Digdag.env.store({name.intern => value})
    puts "stored #{name}:#{value}"
  end
end

$ digdag run parent.dig
2017-02-03 16:16:02 +0900: Digdag v0.9.3
～略～
2017-02-03 16:16:09 +0900 [INFO] (0016@+parent+store1): rb>: StoreVar.store_var
stored parent_store_var_4:parent_store_var_4_value
2017-02-03 16:16:11 +0900 [INFO] (0016@+parent+child_call): call>: child_call.dig
2017-02-03 16:16:12 +0900 [INFO] (0016@+parent+child_call^sub+store1): rb>: StoreVar.store_var
stored child_call_store_var_2:child_call_store_var_2_value
2017-02-03 16:16:13 +0900 [INFO] (0016@+parent+child_call^sub+env1): sh>: env | grep _var_ | grep -v _command= | sort
child_call_export_var_1=child_call_export_var_1_value
child_call_store_var_2=child_call_store_var_2_value
child_include_export_var_1=child_include_export_var_1_value
parent_export_var_1=parent_export_var_1_value_override_by_child_call_export
parent_export_var_2=parent_export_var_2_value_override_by_child_include_export
parent_export_var_3=parent_export_var_3_value
parent_store_var_4=parent_store_var_4_value
2017-02-03 16:16:14 +0900 [INFO] (0016@+parent+env1): sh>: env | grep _var_ | grep -v _command= | sort
child_call_store_var_2=child_call_store_var_2_value
child_include_export_var_1=child_include_export_var_1_value
parent_export_var_1=parent_export_var_1_value
parent_export_var_2=parent_export_var_2_value_override_by_child_include_export
parent_export_var_3=parent_export_var_3_value
parent_store_var_4=parent_store_var_4_value
2017-02-03 16:16:15 +0900 [INFO] (0016@+parent+store2): rb>: StoreVar.store_var
stored parent_store_var_5:parent_store_var_5_value
2017-02-03 16:16:16 +0900 [INFO] (0016@+parent+store): rb>: StoreVar.store_var
stored child_include_store_var_2:child_include_store_var_2_value
2017-02-03 16:16:17 +0900 [INFO] (0016@+parent+env): sh>: env | grep _var_ | grep -v _command= | sort
child_call_store_var_2=child_call_store_var_2_value
child_include_export_var_1=child_include_export_var_1_value
child_include_store_var_2=child_include_store_var_2_value
parent_export_var_1=parent_export_var_1_value
parent_export_var_2=parent_export_var_2_value_override_by_child_include_export
parent_export_var_3=parent_export_var_3_value
parent_store_var_4=parent_store_var_4_value
parent_store_var_5=parent_store_var_5_value
2017-02-03 16:16:17 +0900 [INFO] (0016@+parent+env2): sh>: env | grep _var_ | grep -v _command= | sort
child_call_store_var_2=child_call_store_var_2_value
child_include_export_var_1=child_include_export_var_1_value
child_include_store_var_2=child_include_store_var_2_value
parent_export_var_1=parent_export_var_1_value
parent_export_var_2=parent_export_var_2_value_override_by_child_include_export
parent_export_var_3=parent_export_var_3_value
parent_store_var_4=parent_store_var_4_value
parent_store_var_5=parent_store_var_5_value
2017-02-03 16:16:18 +0900 [INFO] (0016@+parent+store3): rb>: StoreVar.store_var
stored parent_store_var_6:parent_store_var_6_value

わかったこと：

子をcallで実行した場合のタスク名は+parent+child_call^sub+env1、子をincludeで実行した場合のタスク名は+parent+env。call時には「+<子dig名>^sub」が挟まるがinclude時には挟まらない。includeは「親自身が実行した」ことになっている感じ。
親のexportでの「変数の定義」はcallした子にもincludeした子にも伝わる。
callした子のexportでの「親変数の上書き」「変数の定義」は親には伝わらない。
includeした子のexportでの「親変数の上書き」「変数の定義」は親に伝わる。というかincludeは「親自身が実行した」ことになっている。だから親のexportで定義した変数と一緒に他の子にも伝わっている。
Rubyでstoreした変数は親/callした子/includeした子のどこでstoreしてもその後の全体に伝わる。
親digにおいてincludeはcallよりも後に書いてあるのに、callした子の実行時点で既にincludeした子のexportでの「親変数の上書き」「変数の定義」は実行済。