The ESP_WifiManager_lite has some very compelling good points in favour of the original Tzapu WiFiManager, which takes quite some flash rom space.
This library has also quite some following and has been maintained for quite some years (2021-2023) , but is now in Archived state.
One of its big plus points is that despite being a 'Lite' version, it has quite some positive extra features, such as
- allow multiple (2) WiFi stations to be pre-configured. Good when device is portable it can be used in wider range.
- allow to configure other parameters as well. Helpful that the main application doesn't have to have a web configuration page.
- allow to re-enter configuration page when wifi connection is still good, by using the double or multiple reset detection feature.

Looking into the code and into its behaviour, there are quite some questions and
- the number of configuration parameters are overwhelming
- the functionality of the double reset detector and multi reset detector are overlapping such that there shouldn't need to serve both; the MRD can do the job of DRD, so DRD should have been removed.
- The MRD / DRD have far too many config parameters; the should not have to store their status in non-volatile memory (flash emulated EEPROM or filesystem), especially when you can expect write interruption by a next reset, which can easily corrupt that flash storage.
- it looks that some of those 'extra' features are not well thought out. It looks like bringing extra features, perhaps to satisfy someone's request, was more important.
- The Wifi Manager Filesystem (SPIFFS/LittleFS) does function better than the EEPROM stored version
- The EEPROM version suffers from improper initial configuration (default configuration setup is not used), values entered before are lost on next run.

The fact that Multi Wifi stations is limited to 2, brought me to create my own version, and also tackling other issues found underway.

Questions about the ESP_MultiResetDetector

- Suggestion is to remove all Flash FS or EEPROM R/W and only use RAM / RTC RAM.
  With these, (configuration-) complexity will be reduced greatly! Also the Flash size.

- The implementation suggest that RTC RAM storage is only available on ESP8266.
  However there is also simple solution for the ESP32; to place reset flag in slow RTC RAM:
  `RTC_NOINIT_ATTR uint32_t noinit_multiResetDetectorFlag;`
  or use normal ram that isn't initialized by reset/application restart:
  `__NOINIT_ATTR uint32_t noinit_multiResetDetectorFlag;`

- The library generates compile warnings that are no warnings at all, but notions about configuration choices. Why?

Questions about the ESP_WifiManager_lite

-

ESP_WiFiManager_Lite issues
- NUM_WIFI_CREDENTIALS is fixed to 2 in ESP_WiFiManager_Lite.h,
  however the remaining code appears to be suited for a flexible number.
  What is the decision behind the fixed number?
  => the webpage markup isn't suited for != 2
  ==> done this myself, since the library is now unmaintained it is now included as lib.

- Why two different solutions doing basically the same: DOUBLERESETDETECTOR (DRD) or MULTIRESETDETECTOR (MRD) ? get rid of one

- When either using DOUBLERESETDETECTOR (DRD) or MULTIRESETDETECTOR (MRD) there is for ESP8266 no possibility to
  configure to use RTC memory to store reset state, although the config options suggest this possibility.
  The library source needs to be changed to configure for ESP8266_MRD_USE_RTC  or ESP8266_DRD_USE_RTC
  What is the reason behind this?
  --> The RTC memory variant appears to be un-implemented on DRD, and only for ESP8266 on MRD
  ==> select EEPROM to be used for wifi settings and DRD; these won't be erased by FS upload.
   ( can't independently select storage option for DRD and wifi manager ; USE_LITTLEFS counts for both)

- Always output warning:
 .pio\libdeps\default\ESP_WiFiManager_Lite\src/ESP_WiFiManager_Lite.h:95:6: warning: #warning Using EEPROM in ESP_WiFiManager_Lite.h [-Wcpp]
   95 |     #warning Using EEPROM in ESP_WiFiManager_Lite.h
  ==> disabled; warning serves no purpose; there is nothing wrong
  ==> placed all under log level 4

- The ESP_WiFiManager_Lite has way too many configuration parameters, of which some are unexpliccably fixed in the library.
  Storing the (MRD/DRD) reset detector flags in the filesystem and writing them while expecting resets is not a good idea.
  They should be stored in some memory that is not cleared upon reset (__NOINIT_ATTR on ESP32, RTC memory on ESP8266).

- In both DRD and MRD implementation, the main flag (uint32_t) is double defined, both in uppercase and lowercase.
  The significance of that is beyond me, it appears to serve no purpose; probably has to do with some external modification history...

- The name 'Customs' appears on many places. Is this a spelling mistake is really meant? Obviously 'Custom' is meant. I suppose the the library originator had one too many interaction with US Customs :-)

- The examples for defaultConfig suggest to set header to "ESP8266" and claim "char header[16], dummy, not used",
however, the code checks on several instances that header MUST contain "ESP_WM_LITE", and rejects it otherwise!
  otoh, most but not all of the 6 cases where the defaultConfig is copied to the internal configuration, the header is re-written with the "ESP_WM_LITE" name.

- in function getConfigData() (both for FS and EPROM), there are 2x `if (LOAD_DEFAULT_CONFIG_DATA)`, however at the first it already has returned from the function, so the 2nd is never reachable.
  Also, uppercase `LOAD_DEFAULT_CONFIG_DATA` is not a macro but an external variable; they should never be written in uppercase (confusing).
  X rename LOAD_DEFAULT_CONFIG_DATA to LoadDefaultConfigData
  - Changed into Macro "#define LOAD_DEFAULT_CONFIG_DATA true", placed in defines.h of examples

- function `loadAndSaveDefaultConfigData()` naming is confusing, there is no explanation. But there is also no reference anywhere, so it could be removed.
  otoh, when renamed to `restoreDefaultConfiguration()` it says what it does, and can be used at runtime of what `LOAD_DEFAULT_CONFIG_DATA` at build-time forces, and is therefore a smarter approach to testing the library.
  Also, that function appears twice in the class implementation, one for FS and one for EEPROM, yet, it doesn't have anything special for each, so it should be moved to a common part and one instance be removed.

- function `NULLTerminateConfig()` is not used, not called from anywhere, not documented and not FS dependent. can be removed.

- There are multiple functions that pass an boolean value by reference, but declared as const.
  What is the thought behind this?
  It is much simpler and less code to pass by value; the const declaration is unnecessary because the receiving function can't modify it.

  For example, when calling a function with parameter by reference with simple boolean value, means that the compiler must allocate a location on stack containing that value 'true', and then pass the address of that location to the called function.
  With a call by reference, it would load a register with the value and call the function; much simpler and shorter.
```cpp
   setForcedCP(true);

   void setForcedCP(const bool& isPersistent)
   {
   ...
   }
```

- Macro ESP_WML_LOGERROR...  is more than once abused to output information, rather than errors.
  This results in larger than necessary production code because those Serial.prints and strings stay active in release build.
  One trick to get smaller codesize is to define _ESP_WM_LITE_LOGLEVEL_ to -1 instead of the normal 0

- on function `char* getRFC952_hostname(const char* iHostname)`, the following remarks:
  - Why this reference to RFC925? it is old (1985), no longer valid and surpassed by other RFC's,
  - The implementation does not allow '.' inside hostname
  - While the '_' is not allowed by RFC925, it is used in function begin() "ESP_" to set hostname
  - In this size restricted piece of code, pulling in the ctype table costs extra flash
  - The question is, why is there the need to 'correct' a hostname?
  - This function is named get, but behaves like a set function; confusing!
  ==> resolved remarks by
  - renaming getRFC952_hostname to setWmlHostname
  - renaming pivate stored String RFC952_hostname  to wmlHostname
  - not using ctype but self testing for allowed characters {A-Z,a-z,0-9} + {-._} allowed  excluding first and last char.
  - The question: Why? I can't resolve

- The flag `hadConfigData` usage doesn't make any sense at all.
  1 it cleared in getConfigData()
  2 it is assigned to return value of getConfigData() in begin()
  3 it is tested shortly thereafter, and when set, it is set to true
  4 then when it was false, it is set to true when isForcedConfigPortal is true or noConfigPortal is false
  5 In several getter functions, it is tested and when when false , getConfigData() is called
  6 isConfigDataValid() returns the value of hadConfigData
  7 When isWiFiConfigValid() returned false, the hadConfigData is also set to false
  8 In startConfigurationMode(), the hadConfigData determines the config timeout timer; only when set the timer is started (OK)
  ? why is the name set in past tense? (note that library was made by US resident Chinese that often don't know the difference); there are many more signs of weak language usage)
  >5  since getConfigData() does clear but not set that flag, it would be called on every subsequent get function.
  > clearly not designed usage or bad code changes did happen somewhere along the line
  > calls for re-design.


