WAR not accessible after deploy second - wildfly

Question

My Wildfly development environment was set up ok and working. I was able to access my application using https://127.0.0.1:8443 and life was good.
I then deployed a second WAR file for a second application and then my first application became unreachable (either through https://127.0.0.1:8443 or via https://127.0.0.1:8443/WARNAME). The second (new) WAR was accessible via https://127.0.0.1:8443/WARNAME2.
I tried numerous things to get the first WAR to be reachable again (mentioned below to keep this post cleaner) and ultimately decided to back everything out to try and get back to square one to try again - I reset my standalone.xml, web.xml and jboss-web.xml and deleted all the WARs out of the deployment directory, in Eclipse I did a maven->update project, redeployed and no luck. After trial and error, if I delete the jboss-web.xml file, update project and redeploy (using mvn clean package -Dmaven.test.skip=true), I can now access the original app using https://127.0.0.1:8443/WARNAME, but now all my rest calls expect the WAR before the rest name.
Are there other files that Wildfly generates that may not be being cleaned? I googled this and found some temp files to delete for jboss 5 (I am on wildfly 9.0.1.final). I am certain that removing the jboss-web.xml file is not the right answer, but I've spun my wheels for a couple days on this.
Here's some additional information if it helps:
The jboss-web.xml in my original WAR:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.jboss.com/xml/ns/javaee
http://www.jboss.org/j2ee/schema/jboss-web_5_1.xsd">
<context-root>/</context-root>
</jboss-web>
web.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<display-name>hatteras</display-name>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
<mime-mapping>
<extension>ico</extension>
<mime-type>image/x-icon</mime-type>
</mime-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<error-page>
<error-code>404</error-code>
<location>/errors/404.html</location>
</error-page>
<error-page>
<error-code>503</error-code>
<location>/errors/503.html</location>
</error-page>
<security-constraint>
<web-resource-collection>
<web-resource-name>WARNAME</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</web-app>
Snippet from standalone.xml (after I backed out the second deploy.... diff confirms this is how it looked a month ago before I did this experiment):
<subsystem xmlns="urn:jboss:domain:undertow:2.0">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https"/>
<https-listener name="default-ssl" socket-binding="https" security-realm="SslRealm"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<location name="/reports/" handler="ifsreports"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
(.....)
Other things I have tried:
Adding a default-web-module tag to the default host name entry shown above
Removed the <location name="/" handler="welcome-content"/> handler